FoundationDB vs PostgreSQL

Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

FoundationDB
FoundationDB

9
19
+ 1
12
PostgreSQL
PostgreSQL

17.5K
13.3K
+ 1
3.4K
Add tool

FoundationDB vs PostgreSQL: What are the differences?

What is FoundationDB? Multi-model database with particularly strong fault tolerance, performance, and operational ease. FoundationDB is a NoSQL database with a shared nothing architecture. Designed around a "core" ordered key-value database, additional features and data models are supplied in layers. The key-value database, as well as all layers, supports full, cross-key and cross-server ACID transactions.

What is PostgreSQL? A powerful, open source object-relational database system. 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.

FoundationDB and PostgreSQL can be categorized as "Databases" tools.

"ACID transactions" is the primary reason why developers consider FoundationDB over the competitors, whereas "Relational database" was stated as the key factor in picking PostgreSQL.

PostgreSQL is an open source tool with 5.44K GitHub stars and 1.8K GitHub forks. Here's a link to PostgreSQL's open source repository on GitHub.

- No public GitHub repository available -

What is FoundationDB?

FoundationDB is a NoSQL database with a shared nothing architecture. Designed around a "core" ordered key-value database, additional features and data models are supplied in layers. The key-value database, as well as all layers, supports full, cross-key and cross-server ACID transactions.

What is 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.
Get Advice Icon

Need advice about which tool to choose?Ask the StackShare community!

Why do developers choose FoundationDB?
Why do developers choose PostgreSQL?

Sign up to add, upvote and see more prosMake informed product decisions

    Be the first to leave a con
    What companies use FoundationDB?
    What companies use PostgreSQL?

    Sign up to get full access to all the companiesMake informed product decisions

    What tools integrate with FoundationDB?
    What tools integrate with PostgreSQL?
      No integrations found

      Sign up to get full access to all the tool integrationsMake informed product decisions

      What are some alternatives to FoundationDB and PostgreSQL?
      CockroachDB
      Cockroach Labs is the company building CockroachDB, an open source, survivable, strongly consistent, scale-out SQL database.
      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.
      Redis
      Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
      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.
      Couchbase
      Developed as an alternative to traditionally inflexible SQL databases, the Couchbase NoSQL database is built on an open source foundation and architected to help developers solve real-world problems and meet high scalability demands.
      See all alternatives
      Decisions about FoundationDB and PostgreSQL
      Anton Sidelnikov
      Anton Sidelnikov
      Backend Developer at Beamery · | 6 upvotes · 9.2K views
      PostgreSQL
      PostgreSQL
      MongoDB
      MongoDB

      In my opinion PostgreSQL is totally over MongoDB - not only works with structured data & SQL & strict types, but also has excellent support for unstructured data as separate data type (you can store arbitrary JSONs - and they may be also queryable, depending on one of format's you may choose). Both writes & reads are much faster, then in Mongo. So you can get best on Document NoSQL & SQL in single database..

      Formal downside of PostgreSQL is clustering scalability. There's not simple way to build distributed a cluster. However, two points:

      1) You will need much more time before you need to actually scale due to PG's efficiency. And if you follow database-per-service pattern, maybe you won't need ever, cause dealing few billion records on single machine is an option for PG.

      2) When you need to - you do it in a way you need, including as a part of app's logic (e.g. sharding by key, or PG-based clustering solution with strict model), scalability will be very transparent, much more obvious than Mongo's "cluster just works (but then fails)" replication.

      See more
      Yonas Beshawred
      Yonas Beshawred
      CEO at StackShare · | 9 upvotes · 29.9K views
      atStackShareStackShare
      MemCachier
      MemCachier
      PostgreSQL
      PostgreSQL
      Rails
      Rails
      Amazon ElastiCache
      Amazon ElastiCache
      Heroku
      Heroku
      Memcached
      Memcached
      #Caching
      #RailsCaching

      We decided to use MemCachier as our Memcached provider because we were seeing some serious PostgreSQL performance issues with query-heavy pages on the site. We use MemCachier for all Rails caching and pretty aggressively too for the logged out experience (fully cached pages for the most part). We really need to move to Amazon ElastiCache as soon as possible so we can stop paying so much. The only reason we're not moving is because there are some restrictions on the network side due to our main app being hosted on Heroku.

      #Caching #RailsCaching

      See more
      John Kodumal
      John Kodumal
      CTO at LaunchDarkly · | 15 upvotes · 191.6K views
      atLaunchDarklyLaunchDarkly
      Amazon RDS
      Amazon RDS
      PostgreSQL
      PostgreSQL
      TimescaleDB
      TimescaleDB
      Patroni
      Patroni
      Consul
      Consul
      Amazon ElastiCache
      Amazon ElastiCache
      Amazon EC2
      Amazon EC2
      Redis
      Redis
      Amazon Kinesis
      Amazon Kinesis
      Kafka
      Kafka

      As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

      We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

      See more
      Joshua Dean Küpper
      Joshua Dean Küpper
      CEO at Scrayos UG (haftungsbeschränkt) · | 5 upvotes · 53.4K views
      atScrayos UG (haftungsbeschränkt)Scrayos UG (haftungsbeschränkt)
      MariaDB
      MariaDB
      PostgreSQL
      PostgreSQL
      GitLab
      GitLab
      Sentry
      Sentry

      We primarily use MariaDB but use PostgreSQL as a part of GitLab , Sentry and @Nextcloud , which (initially) forced us to use it anyways. While this isn't much of a decision – because we didn't have one (ha ha) – we learned to love the perks and advantages of PostgreSQL anyways. PostgreSQLs extension system makes it even more flexible than a lot of the other SQL-based DBs (that only offer stored procedures) and the additional JOIN options, the enhanced role management and the different authentication options came in really handy, when doing manual maintenance on the databases.

      See more
      Alex A
      Alex A
      Founder at PRIZ Guru · | 6 upvotes · 8.5K views
      atPRIZ GuruPRIZ Guru
      MySQL
      MySQL
      PostgreSQL
      PostgreSQL

      One of our battles at the very beginning of the road was choosing the right database. In fact, our first prototype was built on MySQL and back then nothing else was even under a consideration (don't ask me why). At some point, I was working on a project which was running on PostgreSQL and it is only then I understood the full power of it. We have over a billion of records in production instance, and we are able to optimize it to run fast and reliable. Well, now my default DB is PostgreSQL :)

      See more
      Tim Nolet
      Tim Nolet
      Founder, Engineer & Dishwasher at Checkly · | 8 upvotes · 64.7K views
      atChecklyHQChecklyHQ
      PostgreSQL
      PostgreSQL
      Heroku
      Heroku
      Node.js
      Node.js
      MongoDB
      MongoDB
      Amazon DynamoDB
      Amazon DynamoDB

      PostgreSQL Heroku Node.js MongoDB Amazon DynamoDB

      When I started building Checkly, one of the first things on the agenda was how to actually structure our SaaS database model: think accounts, users, subscriptions etc. Weirdly, there is not a lot of information on this on the "blogopshere" (cringe...). After research and some false starts with MongoDB and Amazon DynamoDB we ended up with PostgreSQL and a schema consisting of just four tables that form the backbone of all generic "Saasy" stuff almost any B2B SaaS bumps into.

      In a nutshell:cPostgreSQL Heroku Node.js MongoDB Amazon DynamoDB

      When I started building Checkly, one of the first things on the agenda was how to actually structure our SaaS database model: think accounts, users, subscriptions etc. Weirdly, there is not a lot of information on this on the "blogopshere" (cringe...). After research and some false starts with MongoDB and Amazon DynamoDB we ended up with PostgreSQL and a schema consisting of just four tables that form the backbone of all generic "Saasy" stuff almost any B2B SaaS bumps into.

      In a nutshell:

      • We use Postgres on Heroku.
      • We use a "one database, on schema" approach for partitioning customer data.
      • We use an accounts, memberships and users table to create a many-to-many relation between users and accounts.
      • We completely decouple prices, payments and the exact ingredients for a customer's plan.

      All the details including a database schema diagram are in the linked blog post.

      See more
      Łukasz Korecki
      Ł