PGDay Lowlands2026

D1: PostgreSQL for everything

The new CTO of the company has decided that now we will use PostgreSQL for everything. Not "almost" everything, but really everything. Not only will new projects be deployed using PostgreSQL, but everything running other databases must progressively migrate to PostgreSQL, including NoSQL databases, warehouses, lakehouses, and analytics... everything! The question is: as much as we love PostgreSQL, should we implement such a policy for everything?

If you want to participate in this debate, choose the track "D1: PostgreSQL for Everything"

• If you agree with the CTO, use "D1: In favor" as the title of your submission, followed by your arguments in the abstract as why we should use Postgres for everything in the realm of databases.
• If you disagree with the CTO, use "D1: Against" as the title of your submissions, followed by your arguments in the abstract.

D2: Business Logic in the application or in the database

A new project in the company is kicking off and the development teams have gathered to take an important decision. Implement the business logic in the application, or directly in the database as a series of store procedures. Those in favor of coding in the application don't want a "fat database" or "thick database". Those in favor of putting the code in the database want the computation to be closer to where the data is. And even when the Project leader suggests applying the Pareto Principle (aka 80/20 rule), the discussion remains about where to put the 80% of the business logic: in the application or in the database?

If you want to participate in this debate, choose the track "D2: Business Logic in application or database"

• If you want the business logic to be developed in the application code, Use "D2: In the application" as the title of your submission, followed by your arguments in favor of this idea in the abstract.
• If you want the business logic to be closer to the data, use "D2: In the database" as the title of your submissions, followed by your arguments in favor of this idea in the abstract.

D3: Agentic Database Access

Developers at a company are using AI agentic tools for daily development tasks. Several database IDEs have begun supporting AI assistants that help developers run dynamic, read-only queries with less friction and increase productivity. At the same time, developers are also experimenting with SKILL files that teach agents how to interact with internal systems, including databases, by encoding common workflows, query patterns, operational assumptions, and task-specific instructions. But once agents understand how to work with databases, the boundary can quickly move beyond query assistance: creating and dropping indexes, installing extensions, and shifting from CRUD actions into data lifecycle management.

A second faction argues this approach is too risky. They propose that the DBA team instead expose a controlled MCP server, one that restricts agents to a predefined set of queries which developers' local agentic tools can connect to directly. A third faction says databases should be off-limits to agents entirely. What's the correct decision?

If you want to participate in this debate, choose the track "D3: Agentic database access"

• If you think AI agents should have all the access they need to the database, use "D3: In favor" as the title of your submission, followed by your arguments in the abstract.
• If you think that AI agents should have restricted access defined by the DBA team, use "D3: Restricted access" as the title of your submission followed by your arguments in the abstract.
• If you think that databases should be off-limits to agents entirely, use "D3: Against" as the title of your submission, followed by your arguments in the abstract.

D4: One Big database vs Many smaller ones

Your company's PostgreSQL deployment has grown rapidly over the past few years. You now run a large, central "monolithic" database, hosted on a single PostgreSQL cluster, serving multiple applications and teams. Performance tuning, schema changes, and operational coordination are becoming increasingly complex.

The CTO is considering a major architectural shift: either double down on the single database (scaling up the existing PostgreSQL cluster and optimizing it internally), or split the system into multiple smaller, independent databases (per service, per domain, or per tenant).

This decision will impact scalability, operational complexity, team autonomy, and long-term maintainability.

If you want to participate in this debate, choose the track "D4: One big database or many smaller ones".

• If you think it is better to scale up, use "D4: One big database" as the title of your submission, followed by your arguments in the abstract.
• If you think a set of smaller databases is better, use "D4: Many smaller databases" as the title of your submission, followed by your arguments in the abstract.