- more IOPS
- 30%
- cost reduction
- 10%
YNAB is an app that guides spending decisions through a simple set of habits, and is backed by a large online user community. YNAB has a large database footprint to support its production application as well as dozens of development environments. As YNAB’s user base was growing, so was its database and running up against Heroku’s soft 4TB limit.
Scaling with vanilla Postgres
The YNAB team knew they needed to scale their database and reviewed several sharding options, including Citus (Hyperscale). With some initial tests, they noticed issues with the use of PL/pgSQL and worried that their heavy use of native Postgres tools would cause issues with sharding solutions. After testing and discussion, YNAB decided to separate their database uses at the application level, giving them similar tools and a bigger footprint, but continuing to stay on vanilla Postgres.
We decided to stay on vanilla Postgres to make sure we had all the Postgres features our team uses and knows.
Brady HoltSoftware Developer at YNAB
Staying on vanilla Postgres allows YNAB to stay free of vendor lock-in, get Postgres versions and patches quickly, and never have to worry about compatibility issues. Everything at Crunchy Data is open source, not ‘Postgres compatible’, making it even easier to scale the application and team.
Postgres vendor search
YNAB set out on a vendor search to get Postgres support on AWS. There are quite a few options so they spoke with several teams and performed technical reviews and tests to ensure performance, compatibility, and cost planning. Their findings were as follows.
Amazon Aurora: YNAB’s benchmarking showed no material boost in performance throughout with Aurora compared to other Postgres deploys inside AWS. They also had trouble estimating future spend in production and fully understanding the pricing model. Plus, they really wanted to stay on vanilla Postgres and weren’t excited about possible vendor lock-in on Aurora.
Amazon RDS: In testing RDS, YNAB ran into some unexpected performance hangs when testing and concluded it was likely related to their heavy usage of PL/pgSQL. They also noticed the possibility of creating snapshots could result in a brief I/O suspension on the primary machine. And they were concerned that they would not have the ear of Amazon support to work through issues, like performance and I/O suspension, and wanted a vendor that could be more hands-on.
We wanted to work with a vendor that knew us and would advocate for our needs. We were concerned we wouldn't get high quality support since we'd be a small fish in a big AWS pond.
Taylor BrownTechnical Fellow at YNAB
Aiven: YNAB also reviewed Aiven and their PCIe NVMe disks. They were concerned about snapshotting and crash recovery and risks associated with that setup. Also, with Aiven, they do more than just Postgres and YNAB liked the idea of a vendor where Postgres was their "bread-and-butter".
YNAB’s team was really comfortable with the Heroku tooling including with the forks and APIs. They really liked that Crunchy had similar developer tools.
In the end, Crunchy Bridge met all of YNAB’s requirements:
- Vanilla Postgres
- Consistent performance - Risk management
- High quality support
- Familiar developer tools
Optimizing spend with superuser
YNAB was particularly concerned with optimizing spend and making sure they got all the IOPS they could with their application. On Heroku, they maxed out at 60k IOPS, but with Crunchy’s disks they’re able to get 80k IOPS.
Crunchy Bridge also offers superuser, which was missing from Heroku. They are now able to use superuser to create more than one database per cluster, which is letting them create development environments more cost effectively. They estimate that their new setup is saving them about 10%.
We love having real superuser access. It helps us optimize our spending and configure our clusters just how we need them to be.
Brady HoltSoftware Developer at YNAB
With superuser, YNAB is also really excited using logical replication inside Postgres. They are able to use replication with Fivetran to ingest business analytics into Snowflake, streamlining and simplifying some of their data flow and processes.
More confidence with Crunchy Bridge Support
One of the primary reasons for moving to Crunchy Bridge was the support and YNAB has been really happy with the team.
We have been really happy with the support. Support is one of the main reasons we went to Crunchy and we haven't been disappointed yet.
Brady HoltSoftware Developer at YNAB
In particular YNAB has expressed that they really like being able to work with Crunchy’s hands-on support through screen shares and video calls. The YNAB and Crunchy support team recently did a full credential rotation and YNAB was glad to have the extra hands, just in case something unexpected happened.
We never had the ability to work with Postgres support and just jump on a screen share before. In the past it was all over support tickets. Now we’re able to have more hand holding when we need it and that just gives us so much more confidence.
Brady HoltSoftware Developer at YNAB