Today, as part of our Launch Week (Day 4), we're excited to announce the release of our Postgres how-to guides collection – a comprehensive set of dozens of practical guides covering real-world PostgreSQL challenges.
I'm excited to announce that Postgres AI has started work on a new project – open-source Self-Driving Postgres (SDP).
In the AI era, Postgres is the natural choice for AI builders. With fast-growing database clusters, the highest level of automation is essential. AI-driven growth demands efficient, proactive, and intelligent database management. Our goal is to reduce manual interventions as much as possible to achieve the highest level of operational efficiency and reliability.
Preview environments are temporary deployment environments created for each pull request, offering major advantages over traditional shared staging environments. While platforms like Vercel (paid) and Coolify (open-source) solve application deployment, the database remains the bottleneck. Teams typically compromise: sharing one database (causing conflicts), deploying small test databases (lacking realistic data), or cloning large production databases (taking hours and costing heavily). DBLab 4.0's database branching solves this with O(1) economics, spinning up isolated production-scale Postgres clones in seconds for cost-effective full-stack previews.
This is Day 3 of Postgres AI launch week
It starts innocently enough.
You choose Postgres – solid, reliable, battle-tested. You pick a managed service like RDS or CloudSQL. They handle backups, high availability, disaster recovery. You can focus on building your product. Life is good.
Your startup grows. Users love what you've built. Data accumulates – gigabytes become terabytes. Traffic surges – hundreds of requests become thousands per second.
Then one day, everything changes.
Queries that ran in milliseconds now take seconds. Connection pools max out during peak hours. Replication lag appears out of nowhere. Your perfectly fine database suddenly isn't fine at all.
You reach out to your managed service support. The response? A generic checklist. "Have you tried increasing your instance size?" Days pass. Your users complain. Your team scrambles. The support ticket remains open, unhelpful.
This is when you realize: nobody cares about your database health as much as you do.
This is exactly when it's time to engage Postgres AI.
For 5+ years, the Postgres AI team has been rescuing companies from exactly this situation. Our clients include GitLab, Miro, Chewy, Midjourney, ClickUp, Photoroom, Gamma, Suno, Supabase – they faced a lot of database challenges during hypergrowth.
Our approach: comprehensive health checks using a methodology refined over hundreds of engagements. We call it Postgres AI Checkup – it identifies current issues and predicts future ones before they cripple your business.
Last year alone, we conducted 30+ deep checkups for 20+ companies. Today, we're launching this as a scalable service, enhanced with AI automation while keeping human experts at the core.
Start your first checkup: Console.Postgres.ai
Today we're launching the SQL query toolkit, a tool to analyze, explore, and share SQL queries with plans, that lives inside Postgres AI Console.
Today we're releasing postgres_ai monitoring v0.7, an open-source monitoring solution built specifically for Postgres experts who need rapid root cause analysis and deep performance insights. This isn't a tool for beginners—it's designed for experienced DBAs and SREs who need to understand complex performance issues in minutes, not hours.
Want to see it in action? Try our live demo (login: demo / password: demo) to explore the dashboards and see real-time Postgres monitoring in action.
The cost of experimentation determines the pace of innovation. In database development, this cost has traditionally been measured in hours and thousands of dollars per environment. DBLab Engine 4.0 changes this equation fundamentally with instant database branching.
New version delivers comprehensive database branching for Postgres with unique set of characteristics:
In one of the recent PostgresFM episodes, Michael Christofides and Nikolay discussed planning time and what can affect it. One of the obvious negative factors we've discussed is the large number of partitions a partition table might have.
In this post, we're using our Postgres.AI assistant to see how planning time depends on the number of partitions.
This is the very first blog post of its kind: it has an integrated AI that you can use to explore the topic discussed here further, to repeat the experiment, alter it in any direction, and study the Postgres behavior more effectively.
I'm happy to present our new product, Postgres.AI Bot. It is powered by OpenAI's GPT-4 Turbo and is designed to help engineers improve their experience when working with PostgreSQL. This bot has a vast knowledge base with over 110,000 entries, including documentation, source code for different PostgreSQL versions, and related software like PgBouncer, Patroni, and pgvector. It also integrates expert articles and blogs.
In addition, the bot can conduct two types of experiments to verify ideas:
Our ambitious goal for 2024 – conduct 1 million database experiments in both shared and dedicated environments, aiding both the bot's knowledge and the improvement of these projects, particularly in performance. To achieve this, we became a part of Google Cloud's AI startup program.
In this blog post, we discuss some details of how the bot is implemented, what it is capable of, share its first exciting achievements, and talk about the future.
DBLab Engine version 3.4, an open-source tool for PostgreSQL thin cloning and database branching, has been released with numerous improvements.
Rapid, cost-effective cloning and branching are extremely valuable when you need to enhance the development process. DBLab Engine can handle numerous independent clones of your database on a single machine, so each engineer or automated process can work with their own database created within seconds without additional expenses. This enables testing of any changes and optimization concepts, whether manually or in CI/CD pipelines, as well as validating all the concepts suggested by ChatGPT or another LLM. This effectively addresses the issue of LLM hallucinations.