Every application developer and DB admin comes across the scenario where you're expected to be an intermediary between the database and your non-technical colleagues.

Have you ever faced these situations:

1. Run queries to answer questions for business teams, and they often have a lot of questions.
2. Receive urgent emails asking us to fix something in production data, because a business team member made a mistake in the data they provided to you earlier.
3. Receive large spreadsheets that you have to end up cleaning and importing into the database, and you continue receiving updates in form of spreadsheets.
4. End up building custom in-house products to make it easier for your non-technical colleagues to edit values of a single column in a table.

All of these are tasks that hinder us from doing the jobs we were hired to do, supporting technical infrastructure. In an ideal world, we'd expect our non-technical colleagues to be able to use the database themselves, and PostgreSQL has elaborate access mechanisms for that very purpose, but that's still a distant dream.

How do we bridge this database divide and make the power of databases accessible to non-technical people (and make life easier for developers)?

With databases being around for over six decades, and FOSS database ecosystems like PostgreSQL being in active development for over 35 years, why is it only accessible to people who are tech savvy?

Why isn't using a database as common and popular as using a spreadsheet?

My talk will take a stab at answering these questions, provide reasons why it's important to make business teams know what a database is, showcase lessons learnt from interacting with users of all skill levels, and provide ideas on things you can do to make your non-technical colleagues start using databases in a way that wouldn't affect your workflow.

I'll also talk about tools that you can use to achieve these outcomes, including (but not limited to) Mathesar, the open source project I work on.