Last week we saw Uber’s move away from Postgres to MySQL get a lot of attention. This week we get a few well reasoned responses from the Postgres community which include some areas we can improve, as well as some highlights of why what they were trying to do didn’t make as much sense in Postgres.
You’ve added the INDEXes, both partial and covering. You’ve VACCUUM ANALYZEd. You JOINed and INNER JOINed everything to a single query. And yet, your report is still taking too long. What do you do when the low-hanging fruit has been harvested?
Backups are key to keeping your data safe, but there is more than one option… And each has its benefits and trade-offs. Here’s a good summary of when and why you should use each.
We know the frustration. You see all the places your app could be so much better, but you can't seem to convince your boss. Next time, mention Corgibytes. Our Code Inspection™ can help you explain technical improvements in a way executives can understand.
The next major release of Postgres (after 9.6) will be known as
PostgreSQL 10 and development is getting underway. Get an overview and start to follow along with such patches as this one.
Setting up a data pipeline with Python that takes currency exchange rates, stores them in PostgreSQL and then caches the latest exchange rates in Redis.
Time is common in lots of applications, and working with them in Postgres can be incredibly powerful. Here’s a rundown for Rails developers on how you can do it more natively.
