Alternatives to Azure Cosmos DB logo

Alternatives to Azure Cosmos DB

Azure SQL Database, MongoDB Atlas, MongoDB, Neo4j, and MySQL are the most popular alternatives and competitors to Azure Cosmos DB.
580
1.1K
+ 1
130

What is Azure Cosmos DB and what are its top alternatives?

Azure Cosmos DB is a globally distributed, multi-model database service by Microsoft that allows users to elastically and independently scale throughput and storage across any number of Azure regions. Key features include support for multiple data models (document, key-value, graph, column-family), guaranteed low latency, multi-region replication, and automatic indexing. However, some limitations include high cost for small workloads, complexity in managing throughput, and limited support for complex queries.

  1. MongoDB: MongoDB is a popular open-source NoSQL database that offers flexibility in data modeling and scalability. It supports document-oriented storage, sharding for horizontal scaling, and rich query capabilities. Pros: Flexible schema design, suitable for large-scale applications. Cons: May require more manual management compared to Azure Cosmos DB.
  2. Couchbase: Couchbase is a distributed NoSQL database with support for key-value and document data models. It offers high performance, built-in caching, and easy scalability. Pros: High performance, built-in caching, and easy scalability. Cons: Limited support for complex querying compared to Azure Cosmos DB.
  3. Amazon DynamoDB: DynamoDB is a serverless NoSQL database service provided by AWS that offers seamless scalability, high availability, and low latency. Pros: Fully managed service, seamless scalability. Cons: Limited querying capabilities compared to Azure Cosmos DB.
  4. Google Cloud Firestore: Firestore is a flexible, scalable database service by Google Cloud that supports real-time updates, offline access, and automatic scaling. Pros: Real-time updates, offline access. Cons: Limited querying capabilities compared to Azure Cosmos DB.
  5. Cassandra: Apache Cassandra is a distributed NoSQL database known for its high availability, fault tolerance, and linear scalability. Pros: High availability, fault tolerance. Cons: Complex setup and management compared to Azure Cosmos DB.
  6. ScyllaDB: ScyllaDB is a highly performant, distributed NoSQL database compatible with Apache Cassandra. It offers low latency, high throughput, and seamless scalability. Pros: High performance, low latency. Cons: Limited querying capabilities compared to Azure Cosmos DB.
  7. RethinkDB: RethinkDB is an open-source, distributed database focused on real-time applications with support for flexible queries and changefeeds. Pros: Real-time functionality, flexible queries. Cons: Limited scalability options compared to Azure Cosmos DB.
  8. ArangoDB: ArangoDB is a multi-model NoSQL database that supports document, graph, and key-value data models. It offers a flexible query language, multi-model transactions, and horizontal scaling. Pros: Multi-model support, flexible query language. Cons: May require more manual management compared to Azure Cosmos DB.
  9. FaunaDB: FaunaDB is a globally distributed, serverless database service that provides real-time, consistent access to data. It offers built-in support for transactions, GraphQL API, and fine-grained access control. Pros: Globally distributed, serverless. Cons: Limited support for complex queries compared to Azure Cosmos DB.
  10. JanusGraph: JanusGraph is an open-source, distributed graph database that supports Apache TinkerPop framework for graph traversal. It offers scalability, high performance, and flexibility in graph modeling. Pros: Support for complex graph queries, high performance. Cons: Steeper learning curve compared to Azure Cosmos DB.

Top Alternatives to Azure Cosmos DB

  • Azure SQL Database
    Azure SQL Database

    It is the intelligent, scalable, cloud database service that provides the broadest SQL Server engine compatibility and up to a 212% return on investment. It is a database service that can quickly and efficiently scale to meet demand, is automatically highly available, and supports a variety of third party software. ...

  • MongoDB Atlas
    MongoDB Atlas

    MongoDB Atlas is a global cloud database service built and run by the team behind MongoDB. Enjoy the flexibility and scalability of a document database, with the ease and automation of a fully managed service on your preferred cloud. ...

  • MongoDB
    MongoDB

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...

  • Neo4j
    Neo4j

    Neo4j stores data in nodes connected by directed, typed relationships with properties on both, also known as a Property Graph. It is a high performance graph store with all the features expected of a mature and robust database, like a friendly query language and ACID transactions. ...

  • MySQL
    MySQL

    The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. ...

  • Cassandra
    Cassandra

    Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL. ...

  • PostgreSQL
    PostgreSQL

    PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions. ...

  • JavaScript
    JavaScript

    JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...

Azure Cosmos DB alternatives & related posts

Azure SQL Database logo

Azure SQL Database

517
492
13
Managed, intelligent SQL in the cloud
517
492
+ 1
13
PROS OF AZURE SQL DATABASE
  • 6
    Managed
  • 4
    Secure
  • 3
    Scalable
CONS OF AZURE SQL DATABASE
    Be the first to leave a con

    related Azure SQL Database posts

    Mathuba Dlamini
    Full Stack Developer at Dimension Data · | 5 upvotes · 9.4K views

    We are embarking on a project of building a Django web application on Microsoft Azure. The debate holding us back is whether to with Azure SQL Database or Azure Database for PostgreSQL. From all the tutorials and video tutorials they use Azure Database for PostgreSQL but one team member is insisting on Azure SQL Database. Please advise of what to consider if I capitulate what database do I need to install locally to get the project moving.

    See more
    Shared insights
    on
    MongoDBMongoDBAzure SQL DatabaseAzure SQL Database

    Hi, I am trying to build a billing system for utilities. It will have a web app and a mobile app too. The USP of this system would be that the mobile application would support offline syncing, basically, let's say while doing the payment the internet goes down then when it's back the payment goes through. Basically, some features could work offline. So I am confused as to which DB to go for. A relational one like Azure SQL Database or a non-relational one like MongoDB?

    See more
    MongoDB Atlas logo

    MongoDB Atlas

    834
    925
    33
    Deploy and scale a MongoDB cluster in the cloud with just a few clicks
    834
    925
    + 1
    33
    PROS OF MONGODB ATLAS
    • 9
      MongoDB SaaS for and by Mongo, makes it so easy
    • 6
      Amazon VPC peering
    • 4
      MongoDB atlas is GUItool through you can manage all DB
    • 4
      Granular role-based access controls
    • 3
      Built-in data browser
    • 3
      Use it anywhere
    • 3
      Cloud instance to be worked with
    • 1
      Simple and easy to integrate
    CONS OF MONGODB ATLAS
      Be the first to leave a con

      related MongoDB Atlas posts

      Praveen Mooli
      Engineering Manager at Taylor and Francis · | 19 upvotes · 3.9M views

      We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

      To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

      To build #Webapps we decided to use Angular 2 with RxJS

      #Devops - GitHub , Travis CI , Terraform , Docker , Serverless

      See more

      Repost

      Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

      Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

      Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

      Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

      See more
      MongoDB logo

      MongoDB

      92.5K
      79.9K
      4.1K
      The database for giant ideas
      92.5K
      79.9K
      + 1
      4.1K
      PROS OF MONGODB
      • 827
        Document-oriented storage
      • 593
        No sql
      • 553
        Ease of use
      • 464
        Fast
      • 410
        High performance
      • 257
        Free
      • 218
        Open source
      • 180
        Flexible
      • 145
        Replication & high availability
      • 112
        Easy to maintain
      • 42
        Querying
      • 39
        Easy scalability
      • 38
        Auto-sharding
      • 37
        High availability
      • 31
        Map/reduce
      • 27
        Document database
      • 25
        Easy setup
      • 25
        Full index support
      • 16
        Reliable
      • 15
        Fast in-place updates
      • 14
        Agile programming, flexible, fast
      • 12
        No database migrations
      • 8
        Easy integration with Node.Js
      • 8
        Enterprise
      • 6
        Enterprise Support
      • 5
        Great NoSQL DB
      • 4
        Support for many languages through different drivers
      • 3
        Schemaless
      • 3
        Aggregation Framework
      • 3
        Drivers support is good
      • 2
        Fast
      • 2
        Managed service
      • 2
        Easy to Scale
      • 2
        Awesome
      • 2
        Consistent
      • 1
        Good GUI
      • 1
        Acid Compliant
      CONS OF MONGODB
      • 6
        Very slowly for connected models that require joins
      • 3
        Not acid compliant
      • 2
        Proprietary query language

      related MongoDB posts

      Shared insights
      on
      Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

      I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

      For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

      1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

      2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

      3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

      See more
      Vaibhav Taunk
      Team Lead at Technovert · | 31 upvotes · 4M views

      I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.

      See more
      Neo4j logo

      Neo4j

      1.2K
      1.4K
      352
      The world’s leading Graph Database
      1.2K
      1.4K
      + 1
      352
      PROS OF NEO4J
      • 70
        Cypher – graph query language
      • 61
        Great graphdb
      • 33
        Open source
      • 31
        Rest api
      • 27
        High-Performance Native API
      • 23
        ACID
      • 21
        Easy setup
      • 17
        Great support
      • 11
        Clustering
      • 9
        Hot Backups
      • 8
        Great Web Admin UI
      • 7
        Powerful, flexible data model
      • 7
        Mature
      • 6
        Embeddable
      • 5
        Easy to Use and Model
      • 4
        Best Graphdb
      • 4
        Highly-available
      • 2
        It's awesome, I wanted to try it
      • 2
        Great onboarding process
      • 2
        Great query language and built in data browser
      • 2
        Used by Crunchbase
      CONS OF NEO4J
      • 9
        Comparably slow
      • 4
        Can't store a vertex as JSON
      • 1
        Doesn't have a managed cloud service at low cost

      related Neo4j posts

      Shared insights
      on
      Neo4jNeo4jKafkaKafkaMySQLMySQL

      Hello Stackshare. I'm currently doing some research on real-time reporting and analytics architectures. We have a use case where 1million+ records of users, 4million+ activities, and messages that we want to report against. The start was to present it directly from MySQL, which didn't go well and puts a heavy load on the database. Anybody can suggest something where we feed the data and can report in realtime? Read some articles about ElasticSearch and Kafka https://medium.com/@D11Engg/building-scalable-real-time-analytics-alerting-and-anomaly-detection-architecture-at-dream11-e20edec91d33 EDIT: also considering Neo4j

      See more
      Stephen Gheysens
      Lead Solutions Engineer at Inscribe · | 7 upvotes · 462.8K views

      Google Maps lets "property owners and their authorized representatives" upload indoor maps, but this appears to lack navigation ("wayfinding").

      MappedIn is a platform and has SDKs for building indoor mapping experiences (https://www.mappedin.com/) and ESRI ArcGIS also offers some indoor mapping tools (https://www.esri.com/en-us/arcgis/indoor-gis/overview). Finally, there used to be a company called LocusLabs that is now a part of Atrius and they were often integrated into airlines' apps to provide airport maps with wayfinding (https://atrius.com/solutions/personal-experiences/personal-wayfinder/).

      I previously worked at Mapbox and while I believe that it's a great platform for building map-based experiences, they don't have any simple solutions for indoor wayfinding. If I were doing this for fun as a side-project and prioritized saving money over saving time, here is what I would do:

      • Create a graph-based dataset representing the walking paths around your university, where nodes/vertexes represent the intersections of paths, and edges represent paths (literally paths outside, hallways, short path segments that represent entering rooms). You could store this in a hosted graph-based database like Neo4j, Amazon Neptune , or Azure Cosmos DB (with its Gremlin API) and use built-in "shortest path" queries, or deploy a PostgreSQL service with pgRouting.

      • Add two properties to each edge: one property for the distance between its nodes (libraries like @turf/helpers will have a distance function if you have the latitude & longitude of each node), and another property estimating the walking time (based on the distance). Once you have these values saved in a graph-based format, you should be able to easily query and find the data representation of paths between two points.

      • At this point, you'd have the routing problem solved and it would come down to building a UI. Mapbox arguably leads the industry in developer tools for custom map experiences. You could convert your nodes/edges to GeoJSON, then either upload to Mapbox and create a Tileset to visualize the paths, or add the GeoJSON to the map on the fly.

      *You might be able to use open source routing tools like OSRM (https://github.com/Project-OSRM/osrm-backend/issues/6257) or Graphhopper (instead of a custom graph database implementation), but it would likely be more involved to maintain these services.

      See more
      MySQL logo

      MySQL

      123.8K
      104.7K
      3.7K
      The world's most popular open source database
      123.8K
      104.7K
      + 1
      3.7K
      PROS OF MYSQL
      • 800
        Sql
      • 679
        Free
      • 562
        Easy
      • 528
        Widely used
      • 489
        Open source
      • 180
        High availability
      • 160
        Cross-platform support
      • 104
        Great community
      • 78
        Secure
      • 75
        Full-text indexing and searching
      • 25
        Fast, open, available
      • 16
        SSL support
      • 15
        Reliable
      • 14
        Robust
      • 8
        Enterprise Version
      • 7
        Easy to set up on all platforms
      • 2
        NoSQL access to JSON data type
      • 1
        Relational database
      • 1
        Easy, light, scalable
      • 1
        Sequel Pro (best SQL GUI)
      • 1
        Replica Support
      CONS OF MYSQL
      • 16
        Owned by a company with their own agenda
      • 3
        Can't roll back schema changes

      related MySQL posts

      Nick Rockwell
      SVP, Engineering at Fastly · | 46 upvotes · 3.6M views

      When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

      So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

      React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

      Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

      See more
      Tim Abbott

      We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

      We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

      And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

      I can't recommend it highly enough.

      See more
      Cassandra logo

      Cassandra

      3.6K
      3.5K
      507
      A partitioned row store. Rows are organized into tables with a required primary key.
      3.6K
      3.5K
      + 1
      507
      PROS OF CASSANDRA
      • 119
        Distributed
      • 98
        High performance
      • 81
        High availability
      • 74
        Easy scalability
      • 53
        Replication
      • 26
        Reliable
      • 26
        Multi datacenter deployments
      • 10
        Schema optional
      • 9
        OLTP
      • 8
        Open source
      • 2
        Workload separation (via MDC)
      • 1
        Fast
      CONS OF CASSANDRA
      • 3
        Reliability of replication
      • 1
        Size
      • 1
        Updates

      related Cassandra posts

      Thierry Schellenbach
      Shared insights
      on
      GolangGolangPythonPythonCassandraCassandra
      at

      After years of optimizing our existing feed technology, we decided to make a larger leap with 2.0 of Stream. While the first iteration of Stream was powered by Python and Cassandra, for Stream 2.0 of our infrastructure we switched to Go.

      The main reason why we switched from Python to Go is performance. Certain features of Stream such as aggregation, ranking and serialization were very difficult to speed up using Python.

      We’ve been using Go since March 2017 and it’s been a great experience so far. Go has greatly increased the productivity of our development team. Not only has it improved the speed at which we develop, it’s also 30x faster for many components of Stream. Initially we struggled a bit with package management for Go. However, using Dep together with the VG package contributed to creating a great workflow.

      Go as a language is heavily focused on performance. The built-in PPROF tool is amazing for finding performance issues. Uber’s Go-Torch library is great for visualizing data from PPROF and will be bundled in PPROF in Go 1.10.

      The performance of Go greatly influenced our architecture in a positive way. With Python we often found ourselves delegating logic to the database layer purely for performance reasons. The high performance of Go gave us more flexibility in terms of architecture. This led to a huge simplification of our infrastructure and a dramatic improvement of latency. For instance, we saw a 10 to 1 reduction in web-server count thanks to the lower memory and CPU usage for the same number of requests.

      #DataStores #Databases

      See more
      Thierry Schellenbach
      Shared insights
      on
      RedisRedisCassandraCassandraRocksDBRocksDB
      at

      1.0 of Stream leveraged Cassandra for storing the feed. Cassandra is a common choice for building feeds. Instagram, for instance started, out with Redis but eventually switched to Cassandra to handle their rapid usage growth. Cassandra can handle write heavy workloads very efficiently.

      Cassandra is a great tool that allows you to scale write capacity simply by adding more nodes, though it is also very complex. This complexity made it hard to diagnose performance fluctuations. Even though we had years of experience with running Cassandra, it still felt like a bit of a black box. When building Stream 2.0 we decided to go for a different approach and build Keevo. Keevo is our in-house key-value store built upon RocksDB, gRPC and Raft.

      RocksDB is a highly performant embeddable database library developed and maintained by Facebook’s data engineering team. RocksDB started as a fork of Google’s LevelDB that introduced several performance improvements for SSD. Nowadays RocksDB is a project on its own and is under active development. It is written in C++ and it’s fast. Have a look at how this benchmark handles 7 million QPS. In terms of technology it’s much more simple than Cassandra.

      This translates into reduced maintenance overhead, improved performance and, most importantly, more consistent performance. It’s interesting to note that LinkedIn also uses RocksDB for their feed.

      #InMemoryDatabases #DataStores #Databases

      See more
      PostgreSQL logo

      PostgreSQL

      97K
      81.2K
      3.5K
      A powerful, open source object-relational database system
      97K
      81.2K
      + 1
      3.5K
      PROS OF POSTGRESQL
      • 763
        Relational database
      • 510
        High availability
      • 439
        Enterprise class database
      • 383
        Sql
      • 304
        Sql + nosql
      • 173
        Great community
      • 147
        Easy to setup
      • 131
        Heroku
      • 130
        Secure by default
      • 113
        Postgis
      • 50
        Supports Key-Value
      • 48
        Great JSON support
      • 34
        Cross platform
      • 33
        Extensible
      • 28
        Replication
      • 26
        Triggers
      • 23
        Multiversion concurrency control
      • 23
        Rollback
      • 21
        Open source
      • 18
        Heroku Add-on
      • 17
        Stable, Simple and Good Performance
      • 15
        Powerful
      • 13
        Lets be serious, what other SQL DB would you go for?
      • 11
        Good documentation
      • 9
        Scalable
      • 8
        Intelligent optimizer
      • 8
        Free
      • 8
        Reliable
      • 7
        Transactional DDL
      • 7
        Modern
      • 6
        One stop solution for all things sql no matter the os
      • 5
        Faster Development
      • 5
        Relational database with MVCC
      • 4
        Full-Text Search
      • 4
        Developer friendly
      • 3
        Great DB for Transactional system or Application
      • 3
        Free version
      • 3
        Excellent source code
      • 3
        Relational datanbase
      • 3
        search
      • 3
        Open-source
      • 2
        Full-text
      • 2
        Text
      • 1
        Multiple procedural languages supported
      • 1
        Can handle up to petabytes worth of size
      • 0
        Native
      CONS OF POSTGRESQL
      • 10
        Table/index bloatings

      related PostgreSQL posts

      Simon Reymann
      Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 10M views

      Our whole DevOps stack consists of the following tools:

      • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
      • Respectively Git as revision control system
      • SourceTree as Git GUI
      • Visual Studio Code as IDE
      • CircleCI for continuous integration (automatize development process)
      • Prettier / TSLint / ESLint as code linter
      • SonarQube as quality gate
      • Docker as container management (incl. Docker Compose for multi-container application management)
      • VirtualBox for operating system simulation tests
      • Kubernetes as cluster management for docker containers
      • Heroku for deploying in test environments
      • nginx as web server (preferably used as facade server in production environment)
      • SSLMate (using OpenSSL) for certificate management
      • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
      • PostgreSQL as preferred database system
      • Redis as preferred in-memory database/store (great for caching)

      The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

      • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
      • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
      • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
      • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
      • Scalability: All-in-one framework for distributed systems.
      • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
      See more
      Jeyabalaji Subramanian

      Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

      We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

      Based on the above criteria, we selected the following tools to perform the end to end data replication:

      We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

      We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

      In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

      Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

      In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

      See more
      JavaScript logo

      JavaScript

      354.7K
      269.7K
      8.1K
      Lightweight, interpreted, object-oriented language with first-class functions
      354.7K
      269.7K
      + 1
      8.1K
      PROS OF JAVASCRIPT
      • 1.7K
        Can be used on frontend/backend
      • 1.5K
        It's everywhere
      • 1.2K
        Lots of great frameworks
      • 897
        Fast
      • 745
        Light weight
      • 425
        Flexible
      • 392
        You can't get a device today that doesn't run js
      • 286
        Non-blocking i/o
      • 237
        Ubiquitousness
      • 191
        Expressive
      • 55
        Extended functionality to web pages
      • 49
        Relatively easy language
      • 46
        Executed on the client side
      • 30
        Relatively fast to the end user
      • 25
        Pure Javascript
      • 21
        Functional programming
      • 15
        Async
      • 13
        Full-stack
      • 12
        Setup is easy
      • 12
        Future Language of The Web
      • 12
        Its everywhere
      • 11
        Because I love functions
      • 11
        JavaScript is the New PHP
      • 10
        Like it or not, JS is part of the web standard
      • 9
        Everyone use it
      • 9
        Expansive community
      • 9
        Easy
      • 9
        Can be used in backend, frontend and DB
      • 8
        Easy to hire developers
      • 8
        No need to use PHP
      • 8
        For the good parts
      • 8
        Can be used both as frontend and backend as well
      • 8
        Powerful
      • 8
        Most Popular Language in the World
      • 7
        Evolution of C
      • 7
        Hard not to use
      • 7
        Versitile
      • 7
        Its fun and fast
      • 7
        Supports lambdas and closures
      • 7
        Love-hate relationship
      • 7
        Photoshop has 3 JS runtimes built in
      • 7
        Nice
      • 7
        It's fun
      • 7
        Popularized Class-Less Architecture & Lambdas
      • 7
        Agile, packages simple to use
      • 6
        Can be used on frontend/backend/Mobile/create PRO Ui
      • 6
        1.6K Can be used on frontend/backend
      • 6
        Client side JS uses the visitors CPU to save Server Res
      • 6
        It let's me use Babel & Typescript
      • 6
        Easy to make something
      • 5
        Client processing
      • 5
        Everywhere
      • 5
        Scope manipulation
      • 5
        Function expressions are useful for callbacks
      • 5
        Stockholm Syndrome
      • 5
        Promise relationship
      • 5
        Clojurescript
      • 5
        What to add
      • 4
        Only Programming language on browser
      • 4
        Because it is so simple and lightweight
      • 1
        Easy to understand
      • 1
        Test
      • 1
        Test2
      • 1
        Subskill #4
      • 1
        Easy to learn
      • 1
        Hard to learn
      • 1
        Not the best
      • 0
        Hard 彤
      CONS OF JAVASCRIPT
      • 22
        A constant moving target, too much churn
      • 20
        Horribly inconsistent
      • 15
        Javascript is the New PHP
      • 9
        No ability to monitor memory utilitization
      • 8
        Shows Zero output in case of ANY error
      • 7
        Thinks strange results are better than errors
      • 6
        Can be ugly
      • 3
        No GitHub
      • 2
        Slow
      • 0
        HORRIBLE DOCUMENTS, faulty code, repo has bugs

      related JavaScript posts

      Zach Holman

      Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

      But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

      But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

      Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

      See more
      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 11.3M views

      How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

      Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

      Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

      https://eng.uber.com/distributed-tracing/

      (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

      Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

      See more