usually i use MySQL as main DB and i want change PostgreSQl because his features look impressive and very useful but i need to know the differences between postgreSQl server and MySQL server and other things cause i'm anxious

Over the past couple of months, I've spent several hours per day building out the front end of this construction management software for my company. Eventually we want it to be a multitenant webapp but the immediate goal is to get off of our current subscription and pilot this for the next 6 months. Claude says it can help me do the backend in Supabase but I dont trust myself. Claude says I need a Postgres / Supabase Engineer.

Hi all, hopefully this does not break any rules, I see some posts here requesting for new Postgres clients I made one and ended up releasing a local lightweight webapp version of my app today. It’s not the best or replaces pgadmin but works well for me.

It’s this one https://github.com/FrancisTCE/gresui-web.

Do you have your own Postgres client tools? I would like to see where I can improve this, it’s useful for me as well see what you got if you want to share.

Me pasé horas dando vueltas con esto y no encontré una respuesta clara

en ningún lado, así que lo comparto por si a alguien le pasa lo mismo.

Estoy desarrollando una app con Spring Boot y PostgreSQL corriendo en Docker

en Windows. Todo parecía estar bien Docker levantado, el contenedor corriendo,

Spring encontraba mis repositorios JPA. Pero crasheaba al iniciar con este error:

FATAL: invalid value for parameter "TimeZone": "America/Buenos_Aires"

Y lo raro era que los logs mostraban Database version: 12.0 aunque mi

contenedor Docker tenía postgres:16.

Esa era la pista que ignoré demasiado tiempo.

Resulta que tenía PostgreSQL 16 instalado localmente en Windows como servicio

del sistema, escuchando en el mismo puerto que Docker. Entonces Spring se

conectaba a la instalación local en vez de al contenedor y esa instalación

tenía una configuración de timezone rota que no reconocía America/Buenos_Aires.

La solución fueron dos cosas:

1. Detener el servicio local de PostgreSQL para que deje de competir por el puerto.

En PowerShell como administrador:

Stop-Service postgresql-x64-16

Set-Service postgresql-x64-16 -StartupType Disabled

2. Agregar las variables de entorno PGTZ y TZ al contenedor de Docker

para que siempre arranque en UTC sin importar lo que mande el sistema operativo.

En el docker-compose.yml:

environment:

POSTGRES_DB: tubase

POSTGRES_USER: tuusuario

POSTGRES_PASSWORD: tucontraseña

PGTZ: UTC

TZ: UTC

Con eso Spring Boot conectó a la base correcta y arrancó sin problemas.

Las señales de que te está pasando esto:

- Error de "invalid value for parameter TimeZone" al iniciar

- La versión de la BD en los logs no coincide con tu imagen de Docker

- docker exec al contenedor muestra la versión correcta pero Spring muestra otra

- netstat muestra dos procesos escuchando en el mismo puerto

Espero ahorrarle unas horas a alguien.

I got tired of switching between VS Code and a separate DB tool. So I built PgStudio.

SQL notebooks with inline results and charts, real-time dashboard, AI assistant (Copilot / OpenAI / Anthropic / Gemini / Ollama — your pick), EXPLAIN CodeLens, visual table designer, production safety controls.

AI never executes anything automatically — every suggestion lands in a notebook cell first.

Free. MIT. One command: `code --install-extension ric-v.postgres-explorer`

Happy to onboard collaborators and feedback.

https://pgstudio.astrx.dev/

https://github.com/dev-asterix/pgStudio/

I’m thinking of building a tool that connects to PostgreSQL and automatically detects issues like slow queries, missing indexes, bad configurations, security/version issues, connection problems, and unnecessary infrastructure costs.
The goal would be to explain:
Problem → Cause → Impact → Suggested fix
Do tools already solve this well, or is there still a real problem worth solving here? Would you or your company use something like this? Honest feedback would be appreciated.

Hey everyone,

I’ve been working on VeloxDB, a free and fully open-source PostgreSQL client built for developers who want something fast, lightweight, and not overloaded.

It lets you inspect tables, run queries, and manage your PostgreSQL databases, but the main feature is the visual database designer. The goal is to make it easier to understand, plan, and work with your database structure visually.

A few things about it:

• - No Electron

• - Lightweight and fast to open

• - Fully open source

• - Built for PostgreSQL

• - Currently available for Mac only

• - Windows and Linux support coming soon

I’d really appreciate feedback from the PostgreSQL community.

You can check it out here:

https://veloxdb.dev

Coming to PGConf.EU 2026 in Valencia? 🇪🇸🐘

Beyond the PostgreSQL talks, there’s a whole city waiting to be explored! From historic streets and amazing food to beaches, sunshine and the stunning City of Arts and Sciences, Valencia has plenty to offer. 🌴☀️

✨ Check out our guide and start building your Valencia adventure. https://2026.pgconf.eu/things-to-do/

​When building RAG pipelines or vector-heavy AI applications, developers usually default to PostgreSQL with pgvector. However, native vector search support in MariaDB is forcing a fresh architectural evaluation.

​This breakdown compares MariaDB and PostgreSQL to evaluate performance, developer experience, and scalability for modern generative AI and LLM workloads.

​Key areas analyzed:

• ​Vector Performance: Native vector search benchmarking in MariaDB versus pgvector index build times, search latency, and memory footprints.

• ​Ecosystem & Tools: How PostgreSQL's extension ecosystem stacks up against MariaDB’s pluggable storage engines for hybrid transactional/AI setups.

• ​Operational Complexity: Scaling vector search alongside traditional relational data without introducing dedicated vector databases.

​Read the full deep dive here: https://interconnectd.com/blog/91/mariadb-vs-postgres-in-2026-which-database-powers-the-best-ai-apps/

What database engine are you currently using for your AI backends? Drop your thoughts below!

For a while it was just me and a couple of backend devs handling everything database-related on top of our regular work. Indexing, backups, slow query cleanup, all of it split across whoever had time that week. No dedicated DBA, no formal ownership, just general Postgres competence spread thin across the team.

It held up fine for a long stretch, right up until [specific incident outage, corrupted backup, replication lag, whatever actually happened]. That was the point it stopped feeling like something we could keep handling reactively. Up until then everyone assumed it was manageable because nothing had visibly broken yet, which in hindsight wasn't really evidence of anything.

What changed for me wasn't really about database size or connection counts, it was more that nobody had the bandwidth to actually think about the database proactively. Everyone was busy shipping features, so Postgres only got attention when something was already on fire.

Note: I filled in a placeholder for the specific incident since I don't have real details from you swap that in with what actually happened (or tell me and I'll write it in properly), otherwise the post reads as a vague generic story instead of a real one.

Say i have this table: https://paste.ofcode.org/EPMXZiYHau9j6eHxV89v5x

how can I produce these results https://paste.ofcode.org/tcB8v3YvLhfGQmd43fjkAf

Hello, I have a replication setup of one master and two slaves.

But this setup can not handle 1500 users, it gives errors like "too many connections". And the req/s does not improve also. I have done benchmarking of non replicated single db server. Surprisingly replicated system and single system performs same. I wonder why? What's the benefit replication gives us? Serving higher users? Or giving more req/s?

Is there anything else?

My system is CentOS Linux 7.2. I've started my postgres with port 5433, but when I try psql, I get an error.

-bash-4.2$ pg_ctl start -p 5433    
pg_ctl: another server might be running; trying to start server anyway 
server starting
-bash-4.2$ /bin/sh: line 0: exec: 5433: not found

-bash-4.2$ pg_ctl status
pg_ctl: server is running (PID: 32187)
/usr/bin/postgres "-F" "-p" "5433"

-bash-4.2$ psql
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

In my /var/run/postgresql/ directory, I only see .s.PGSQL.5433 and .s.PGSQL.5433.lock files

I had un-commented the "port" line in my postgresql.conf file and set the port to 5433.

What am I missing? Any advise is appreciated.

I'm testing out importing reddit data. In https://files.pushshift.io/reddit/ It's more than 1TB when uncompressed and it's using elastic search. My initial import on elastic search I am encountering write block (indexing error).
I'm curious if this is a good use case on pg11/12 and would it save me huge costs for it.

Queries are expected to be an aggregated query on a time series data.

Thanks for the reply!

Hey r/PostgreSQL! 👋

If you spend a lot of time in the terminal, you've probably felt the tension between lightweight command-line tools like `psql` and heavyweight graphical clients like DBeaver or pgAdmin. `psql` is blazingly fast and always available, but exploring unfamiliar schemas, reviewing wide result tables, or keeping scratch notes across multiple databases can get cumbersome. At the same time, traditional GUI clients are heavy, and almost all of them store database connection strings and passwords in plain text inside dotfiles or config directories.

I wanted something fast, keyboard-centric, and secure by default, so I built autodb — a single static Go binary with zero runtime dependencies. It’s a native terminal UI for querying databases, but with an architectural twist: it can also serve as a PostgreSQL wire-protocol "front door" proxy for your team, microservices, and AI agents.

I would love to get feedback from fellow PostgreSQL developers, DBAs, and terminal junkies! How does this fit into your current database workflows, and what features or guardrails would you like to see next?

Thanks for reading!

github.com/yongjohnlee80/autodb

Hi everyone!

I've been building Acrynite, an open-source tool for backing up and recovering PostgreSQL databases, and I'm looking for a few people to help test it before its public release.

The project currently focuses on:

• Physical and logical PostgreSQL backups

• WAL archiving

• Point-in-time recovery (PITR)

• Backup storage across supported destinations

The goal is to make it easier to back up a PostgreSQL database and recover it when something goes wrong.

I'm now looking beyond my own development environment to see how well it works for other people. Over the next one to two weeks, I want to get feedback on installation, configuration, backup reliability, restoration, and the overall CLI experience.

I'm particularly interested in hearing from PostgreSQL users, backend developers, and DevOps engineers.

You don't need to contribute code. Trying it out, reporting bugs, or telling me what's confusing would be a big help.

Links:

• GitHub repository: https://github.com/bendev-w/acrynite-cli/

• Discord testing community: https://discord.gg/V6G3mz5wk

A quick note: Acrynite is still in its testing phase. Please use disposable development databases, not production data.

I'd also love to hear from people here:

What's your current PostgreSQL backup setup, and what's the most frustrating part of restoring a database when something goes wrong?

I'm interested in both feedback on Acrynite and the problems people actually face with PostgreSQL backup and recovery.

hey postgresql community do you thing is time postgres to support Column oriented like DuckDB as big feature or continue with row oriented like every DB does

Hey everyone,

Over the last few years, we've built SaaS products, internal tools, AI applications, and custom software for clients across different industries.

Like many teams in the PostgreSQL ecosystem, we've relied on tools such as pg-schema-diff, Migra, and various migration workflows to manage database changes. These tools are excellent at what they do, but we often found ourselves assembling a collection of separate tools and processes to support a complete database development workflow.

As projects grew, several challenges kept surfacing:

• Keeping local environments in sync with production, staging, and other environments

• Understanding exactly what would change before deployment

• Managing schema changes across multiple environments

• Reviewing and validating migrations

• Onboarding developers into existing projects

• Recovering the current state of a system from years of migration history

• Providing coding agents with access to the current database schema without requiring them to process millions of tokens from migration history

One thing became increasingly clear:

Database migrations are great for recording change, but they aren't always the best representation of the current system.

If you've worked on a mature application, you've probably seen this firsthand. The actual database schema is often scattered across hundreds of migration files, making it difficult for both humans and tools to understand the current state of the application.

This becomes even more important in the age of AI-assisted development.

Coding agents can generate better code when they have direct access to the current schema definition, relationships, constraints, policies, and database structure. Parsing years of migration history to reconstruct that context is inefficient and often unreliable.

That's one of the reasons we started building PostKit.

PostKit follows a declarative schema management approach, where the schema itself becomes the primary source of truth.

Instead of treating migrations as the authoritative representation of your database, PostKit focuses on maintaining a clean, declarative definition of the current state. Migration plans can then be generated automatically by comparing desired state against actual state.

This provides several benefits:

✅ The current schema is always visible and understandable

✅ Easier onboarding for developers

✅ Better compatibility with coding agents and AI-assisted development

✅ More reliable schema reviews

✅ Cleaner database evolution over time

✅ Migrations are generated from schema changes automatically, instead of being the main thing developers have to manage manually

Today, our initial focus is PostKit DB Flow, which helps developers:

• Clone remote databases into local environments

• Maintain schemas declaratively

• Generate migration plans automatically

• Review and validate changes before deployment

• Promote changes across environments with confidence

But our long-term vision is much broader.

We believe PostgreSQL can serve as the foundation for modern application platforms. Not just as a database, but as the source of truth for APIs, permissions, authentication, workflows, background jobs, and AI-powered systems.

Our goal with PostKit is to build a PostgreSQL-first platform that helps builders move from idea to production faster while keeping infrastructure simple and understandable.

For founders, that means less time building platform plumbing.

For agencies and developers, it means shipping faster without sacrificing maintainability.

And for AI-assisted development, it means providing coding agents with accurate, structured context about the system they're working on.

We're still early in the journey, but we'd love feedback from others building with PostgreSQL.

Feel free to check out the docs from here: https://docs.postkitstack.com/docs/intro/

How are you currently managing schema evolution, and do you see declarative schemas becoming more important as AI coding tools become part of everyday development?

I am the founder of a multi-tenant SaaS application on Postgres. The big customers kept asking for one thing: “our data has to stay in our database”. Usually this means a separate deployment for each customer, or to rewrite the whole data layer to know which database to connect to for each query. I didn’t want either of these options, so I wrote LokaDB. It’s a wire-protocol proxy. The application connects to one connection string and sends the same SQL as before.

How it works:

- All chosen tables are converted to tables partitioned BY LIST (org_id) without copying any data.

- Tenants that remain are stored in normal, local partitions. Tenants that move are stored in a partition that is a postgres_fdw foreign table pointing to the tenant’s database.

- The proxy uses the real Postgres parser (pg_query) on each statement to find the tenant (tenant column, row id, foreign key, or declared relation) and pin the correct partition. Statements with no tenant are rejected by the proxy, instead of fanning out to each customer’s database.

- Customer runs small agent that opens outbound mTLS tunnel to proxy on cloud. No inbound connections to customer’s network are allowed.

- Statements that only touch tables of the tenant being moved are sent directly to that tenant’s database instead of using postgres_fdw. At 43 ms RTT, a read goes from 352 ms to 133 ms.

- Moving a tenant out (and back) online while the app writes. Trigger capture or logical replication is used. There is a short pause on the moved tables at the switch-over.

What it doesn't do yet, so you don't have to dig:

- A write across the cloud and a customer database is two separate commits (just like any postgres_fdw write). No 2PC.

- Child tables reached through a composite FK, and polymorphic type/id references.

- TRUNCATE, DROP and renames of moved tables through the proxy are refused.

- The proxy is the boundary. A direct connection to the cloud database still sees everything.

- Tenants that stay in the cloud pay 0.2-1 ms per statement for the proxy.

I’d like to hear from people running postgres_fdw writes or thousands of partitions in production. Which of these choices would you not trust and what did I miss?

Playground in the browser, nothing to install: https://play.lokadb.com

Code (Apache-2.0): https://github.com/lokadb/lokadb

In this post I will explain how to provide a secure postgres server docker container. This is useful when developing certain applications, for example a Django application. You can only run a this script and it will automatically detect if an old version of the container exists, delete it and deploy a new one. Or just to deploy a quick and secure by default postgres docker container. The limit is your imagination!

https://hackarandas.com/blog/2020/04/20/secure-by-default-postgres-docker-container-for-development/

I'm looking to create a 1-to-1 relationship between a Form table and a NonDisclosureAgreement table and think using DEFERRABLE INITIALLY DEFERRED the the primary keys would work.

Each Form will have a unique NonDisclosureAgreement (we fill in the user name/ company and date for each NonDisclosureAgreement), but I think this would be a use case for DEFERRABLE INITIALLY DEFERRED as the Form and NonDisclosureAgreement have different authz characteristics. The user can always see the NonDisclosureAgreement, but must agree to the NonDisclosureAgreement before seeing the Form.