Why heroku choose postgres

This allowed our developers to stay focused on working with the data instead of building the infrastructure to support it. View Docs Heroku Postgres Plans. Why Heroku Postgres? Scale on demand Peaks and valleys in demand are business as usual for data-driven apps. Do more with your data As a fully managed service, Heroku Postgres allows you to focus on getting the most out of your data without the admin overhead.

See Heroku Postgres in Action. Forks Forking a database is just like forking source code. Trusted data integration Heroku Postgres can serve as the heart of a multi-cloud architecture.

Security and compliance At Heroku, trust is our number one value. The plans for the standard tier are:. The Premium tier is designed for production applications that can tolerate up to 15 minutes of downtime in any given month. All premium tier databases include:.

Within the Premium tier, plans have differing memory, connection limits, and storage limits. The plans for the premium tier are:. Heroku offers Heroku Postgres in private spaces for Heroku Enterprise customers. Additionally, Postgres shield plans are available for customers who need compliance-capable databases. For details on our private and shield plans, see the Heroku Postgres and Private Spaces article.

Although a small amount of RAM is used for managing connections and other tasks, Postgres takes advantage of almost all of this RAM for its cache. Learn more about how this works in this article. After a little research mysql is more popular. I have worked for 2 startups in the valley and both of them used postgres. So, had my biased there. Updating the answer. And then regret it. The place I work uses it, the last place I worked used it. Awarded you the answer because of the great links you posted.

Show 1 more comment. El Yobo El Yobo Scott Marlowe Scott Marlowe 7, 3 3 gold badges 21 21 silver badges 21 21 bronze badges. MySQL is much better if you turn on all strictness options to make it pretend it's a real database, rather than silently incrementing timestamps or truncating data that's longer than the specified varchar length, etc.

Postgres just works properly out of the box. Tyler Eaves Tyler Eaves I've heard anecdotally that postgres is more solid as well. I wonder what else they based their decision on. Yea, that's exactly how I'd put it: solid. This whole system, docs included, just reeks of solid engineering, whereas MySQL always was more "eh, that's good enough for the web".

On the other hand, PostgreSQL in particular Heroku's offering has a couple sharp disadvantages for a startup app: The price. Each Postgres connection requires memory, and database plans have a limit on the number of connections they can accept. If you are using too many connections, consider using a connection pooler such as PgBouncer or migrating to a larger plan with more RAM.

Long-running queries and transactions can cause problems with bloat that prevent auto vacuuming and cause followers to lag behind. The reporting threshold for these queries and transactions is currently 1 minute 60 seconds. They also create locks on your data, which can prevent other transactions from running. Consider killing long-running queries with pg:kill. Clients that have improperly disconnected may leave backends in this state, and they should be terminated with pg:kill --force if left open.

Never Used Indexes have not been used since the last manual database statistics refresh. These indexes are typically safe to drop, unless they are in use on a follower.

Low Scans, High Writes indexes are used, but infrequently relative to their write volume. Indexes are updated on every write, so are especially costly on a high write table. Consider the cost of slower writes against the performance improvements that these indexes provide. Seldom used Large Indexes are not used often and take up significant space both on disk and in cache RAM.

These indexes may still be important to your application, for example, if they are used by periodic jobs or infrequent traffic patterns. Index usage is only tracked on the database receiving the query.

If you use followers for reads, this check will not account for usage made against the follower and is likely inaccurate. Because Postgres uses MVCC old versions of updated or deleted rows are simply made invisible rather than modified in place. Under normal operation an auto vacuum process goes through and asynchronously cleans these up. However sometimes it cannot work fast enough or otherwise cannot prevent some tables from becoming bloated. High bloat can slow down queries, waste space, and even increase load as the database spends more time looking through dead rows.

If this occurs frequently you may want to make autovacuum more aggressive. This checks the overall index hit rate, the overall cache hit rate, and the individual index hit rate per table. Databases with lower cache hit rates perform significantly worse as they have to hit disk instead of reading from memory.

Consider migrating to a larger plan for low cache hit rates, and adding appropriate indexes for low index hit rates. The overall cache hit rate is calculated as a ratio of table data blocks fetched from the Postgres buffer cache against the sum of cached blocks and un-cached blocks read from disk. On larger plans, the cache hit ratio may be lower but performance remains constant, as the remainder of the data is cached in memory by the OS rather than Postgres. The overall index hit rate is calculated as a ratio of index blocks fetched from the Postgres buffer cache against the sum of cached indexed blocks and un-cached index blocks read from disk.

On larger plans, the index hit ratio may be lower, but performance remains constant, as the remainder of the index data is cached in memory by the OS rather than Postgres.

The individual index hit rate per table is calculated as a ratio of index scans against a table versus the sum of sequential scans and index scans against the table. Some queries can take locks that block other queries from running. Normally these locks are acquired and released very quickly and do not cause any issues. In pathological situations however some queries can take locks that cause significant problems if held too long. You may want to consider killing the query with pg:kill.

This looks at 32bit integer aka int4 columns that have associated sequences, and reports on those that are getting close to the maximum value for 32bit ints. You should migrate these columns to 64bit bigint aka int8 columns to avoid overflow. An example of such a migration is alter table products alter column id type bigint;.

Changing the column type can be an expensive operation, and sufficient planning should be made for this on large tables. There is no reason to prefer integer columns over bigint columns aside from composite indexes on Heroku Postgres due to alignemnt considerations on 64bit systems. These checks determine how close individual tables are, or a database is, to transaction ID wraparound.

This is a very rare scenario in which due to autovacuum operations being unable to keep up on very frequently updated tables, these tables are in danger of the transaction ID for that table, or database, wrapping around and resulting in data loss. To prevent this, Postgres will prevent new writes cluster wide until this is resolved, impacting availability. This check counts the number of schema are present in the database, returning a yellow warning for over 19 schema, and a red warning over 50 schema.