How much do you really need to know about databases?
Slides and transcript from How much do you really need to know about databases? at EuroPython 2026 in Kraków, Poland on 15 July 2026.
I will add a link to the recording once it's available.
I've included just very brief alt-text for each slide image, but I've also added any links or other essential information into the body of the blog post.
This talk is aimed at application developers, whether or not you already have some database knowledge. And if that's not your profile, you're welcome in any case, because I'm always happy to talk about databases to anyone at all! So, let’s find out how much you really need to know about databases.
Just to reassure you (because you may start to wonder as the talk goes on) that I really do have a life outside databases: this is a photo of me in my happy place, splattered in mud, out on my mountain bike in the French Alps, where I live.
I’m part of the Postgres extensions team at Snowflake, I’m actively involved in PostgreSQL Europe, especially all things diversity and inclusion, and I write and present talks (about databases) at Postgres and Developer conferences.
When asked “What do you want to be when you grow up?” I doubt any kid ever said “a database administrator”.
"Shockingly", not a single person in the room raised their hand when I asked the audience who wanted to be a DBA when they grew up.
I’ve spent my whole career working with databases, as illustrated by this diagram of my roles over the last 25+ years - Junior database administrator, senior database administrator, (so-called) database expert, senior database consultant…
My last 2 job titles; Senior Solutions Architect, and now Senior Software Engineer, are the only ones that don’t contain the word “database”. But I still work exclusively with them.
And even I didn’t want to be a DBA when I grew up!
But, since I’m a database person (did I mention that?) and I live and breathe data, I thought I’d better do some actual research. Maybe I was wrong. Maybe kids do, in fact, say they want to be database administrators when they grow up.
I checked lists of “what kids want to be when they grow up” and “what adults wanted to be when they were little” [1][2][3][4].
And you might be surprised to hear that database administrator
...drumroll please...
didn’t feature in any of the lists.
Vet or Doctor was a popular choice, as was professional footballer. Astronaut, obviously, and even engineer featured in most of the lists.
But not DBA. I couldn’t even find an image to add to the slide.
So I have to concede that maybe (just maybe) not everyone is as passionate about databases as I am.
Obviously, because I love databases so much, I think everyone should want to know everything about databases.
If you don’t want to talk constantly about Boyce-Codd normal form [5], then why not?
If your party trick isn’t to recite the ACID properties of transactions, the different transaction isolation levels [6] available in each of the database management systems and how they differ from the SQL standard, then are you even really living?
(See me afterwards if you need other ideas for sparkling conversation starters for your next dinner party.)
But most of the developers I speak to just want the database to quietly do its thing in the background. Apparently, you want to concentrate on developing your application, not spend your limited time babysitting a database.
And, even as a database lover, I get that!
But honestly, I think databases are beautiful.
Daniele Procida presented a love program - an ode to his favourite camera - written in Python, in his talk “The Attentive Programmer” [7] at PyCon Italia 2024.
It inspired me think about my chosen love language which would, of course, be the entity relationship diagram.
What a beautiful way to represent almost any real-world objects in terms of their attributes and the relationships between them.
I love the fact that there are rules, and syntax, and conventions.
I like the simplicity of the crows-foot notation, and the fact that so much information can be conveyed by just a few little lines
Just from the tiny snippet on the slide, we know that one department can have one or more employees, and that an employee belongs to one and only one department
I like the way that colouring, spacing and organisation of the elements in the diagram can be used to help even a non-technical reader to see how the different concepts and pieces of data fit together.
I’ve been known to lose myself for hours rearranging an ER diagram to look balanced, pretty, untangled, and easy to read.
What better thing to use my love language for than to describe one of my favourite things – I modelled a Postgres cluster!
- My Postgres cluster comprises one or more databases.
- I can define one or more roles or users for the cluster.
- I can create one or more tablespaces.
- Each of the cluster's databases can contain one or more schemas,
- and each table will belong to one of those schemas.
- The tables can also belong to a tablespaces.
- I can define an index on one or more of a table's columns,
- and each column can belong to one or more indexes.
I could go on to model the permissions granted to the roles, and the fact that certain databases have access to certain tablespaces.
I need to think about how changes over time will be modelled – do I want to record the history?
I could add in other object types like views, functions, stored procedures, extensions...
And I’ve not even started to add in the column names or the primary and foreign key columns.
But we'd better stop there for now so I can talk about other things too!
The world of databases is changing.
The traditional DBA role is becoming less common and, like it or not, developers are often expected to manage their own databases.
Even if you don't have to actually look after your own database, it often forms the backbone of your application, so it’s helpful to know how to interact with it and get the most from it.
And, of course, things are changing even more in 2026: AI tools can now produce database code from natural language. And they're actually getting pretty good at it.
But someone has to understand what's been done and make sure the output actually makes sense.
You won't leave this 30 minute talk a database expert - and that's really the whole point.
The point of this talk is to help you to figure out what you actually need to know about databases.
We'll talk about:
- what a DBA does, and which bits of that you need to care about
- The minimum you need to know to keep your database happy
- The bits of the equation that AI is changing, and what stays the same
- And, probably most importantly, where to find help and information so you don't need to memorise any of this.
First, the basics: what even is a DBA? (and please don’t answer that unless you can think of something nice to say)
The general consensus, based on definitions from careers services, DBMS vendors and job sites [8][9][10][11], is that a DBA "uses specialist software to manage and secure computer systems that store data".
Great. That's clear then.
Except that it tells us pretty much nothing at all about what a DBA actually does all day.
So, what does a DBA actually do?
This is a (pretty long) list of DBA responsibilities based on various definitions and sample job adverts.
Apparently, a DBA is expected to:
- design, implement and maintain backup and recovery procedures.
- design and implement security procedures, manage database access.
- monitor the database’s availability, performance, security, space etc.
- do logical and physical data modelling.
- provide 24/7 support and troubleshooting.
- plan, perform and test database software install and upgrades.
- provide database expertise, advice and support to other teams.
- improve database performance, and fix specific performance problems.
- plan for future database size and resource needs.
- create databases.
- design and implement database maintenance procedures.
- make sure data protection rules are obeyed.
"This is fine"
And then there’s the list of skills that a DBA is expected to have.
This chart shows the most frequently requested skills for DBA jobs in the UK. This version is based on 2023 data from IT Jobs Watch [12], but the list has changed very little since then.
It boils down to:
- SQL skills, procedural languages, data integration and ORMs.
- Knowledge of one or more database management systems (Postgres, SQL Server, Oracle).
- Knowledge of various operating systems (Linux, Windows and various cloud environments).
- Performance Tuning, Database Migration, Disaster Recovery.
- High Availability, Replication, Clustering.
- DevOps and automation methodologies and tools.
- Apparently, social skills. I’m not sure what they’re trying to say about DBAs there!
When I did a check to make sure the list was still up to date, social skills ranked even higher in the list!
Just when we seem to be getting some clarity into what a DBA does, it all becomes a bit fuzzy again when you realize that there are lots of different “flavours” of DBA.
The different DBA roles can differ from one organisation to another or even from one team to the next, the division of responsibilities isn’t always clear-cut, and the roles often overlap.
A traditional split is between the Production DBA and Development DBA.
The Development DBA focuses on building and maintaining a database environment that supports application development then, traditionally, throws things over the fence to the Production DBA, who makes sure the databases in your production environment are kept up and running, focusing on things like availability, performance and security.
Maybe you are the development DBA in your organisation, or maybe you have the luxury of having a dedicated development DBA.
In some organisations, the split is between Application DBA (concerned with the logical, application-related aspects of the database) and System DBA (responsible for the underlying software and physical infrastructure).
You might also hear of Datawarehouse DBAs, Cloud DBAs, Database Architects, or even Replication DBAs or Backup and Recovery DBAs who just look after one aspect of database admininstration.
Not all DBAs are even called DBAs.
Databases are getting more autonomous, so there's a shift towards automation, oversight and validation and away from manual tuning and management.
The SRE (site reliability engineer) role has been around for a while; applying engineering and devops principles to system reliability using observability, automation, monitoring, infrastructure as code etc.
The DBRE (database reliability engineer) role takes SRE concepts and adapts them to the specific needs of database systems (backup and recovery, failovers, provisioning database resources etc.). A DBRE needs deep DBA expertise, coupled with strong engineering/devops skills.
The DBRE may be part of the SRE team, or the SRE may also be the DBRE. In a small team, you, the developer may wear all of the hats!
I still remember this quote from Katie McLaughlin’s DjangoCon Europe 2022 keynote “What should you have to worry about” [13]
She pointed out that although you absolutely can run Django by creating a server, installing Django and Postgres and nginx and making it available to the world, there are then all sorts of things to worry about, including:
- server and network availability,
- OS, Django, nginx and Postgres updates,
- database migrations, database administration and backups.
and if you’re the one who's worrying about these things, Katie wondered:
Are you a Django Developer ? or are you a combination Django developer and database administrator and systems administrator and network administrator and full stack engineer and grossly, grossly underpaid?
You really don't need to be an expert in all of that.
You absolutely don’t need to know everything about databases. I certainly don’t know everything about app development, and even that statement makes it sounds as though I know much more than I do!
I know just enough to be able to help developers to get the most out of their databases.
Likewise, you need to know just enough about databases to help you out with the things that are important to you.
My goal is always to introduce the important concepts, and share links and resources so you know where to look (and who to ask) if and when you need to know more.
It's tempting to think things like "AI can write SQL, so why bother to learn it?" but we all know that AI is great at giving plausible but slightly wrong answers.
Broken queries can return wrong results, perform badly, and silently miss edge cases. AI-generated SQL is only useful if you can read it, evaluate it and catch what's wrong.
I've heard lots of people describe AI as a force multiplier, but for that to be a good thing, of course, You need some useful skills and expertise for it to multiply. Otherwise, you're just going to multiply errors and mistakes.
AI can be a great way to generate the first-draft of a query;
describe what results you want in natural language and see what you get.
Use it for boilerplate SQL that's tedious to keep creating manually,
to get a description of what a query does,
or to get help understanding a query execution plan.
The hard stuff still needs your human judgement:
Edge-cases, architecture, business context, making sure a query is really production-ready
High-precision or high-security work (e.g. financial or health applications)
AI on messy, undocumented, legacy databases where the context is still in someone's head is going to be suboptimal.
This is the agenda from my “How to keep your database Happy” talk. My top 5 tips for things you can put in place, without too much effort, to make sure you have a robust, performant database environment.
- Check that a few key configuration parameters are set correctly for your environment and workload.
- Make sure you take regular backups of your database (and test your recovery process).
- Put a high availability architecture in place (or have someone do it for you).
- Make sure the right users/applications can connect to and interact with your database.
- Make sure you know what's going on and can react quickly if something goes wrong.
I had about 3 minutes per item which, unsurprisingly, wasn't nearly enough time to go into the details of everything you need to know to look after your database.
But that's OK. I always include links to the relevant documentation or other useful resources when I give a talk, because I know I can’t cover everything in 30 minutes and that even if I did, people wouldn’t remember most of what I said.
If, when you have to implement something, or when you have a problem, you think “Oh, I vaguely remember Karen saying something about that” and you can go and read up on it, then I feel as though I’ve done something useful
Let's go back to thinking about that really long list of DBA responsibilities. Which of them are relevant to you, as a developer?
You definitely want to have some understanding of how database backup and recovery works. At the very least test a database restore (even for managed services) in case something goes very wrong.
It's helpful to know some database security best practices; for example principle of least privilege, connection and authentication methods etc. So you can define who owns and is able to manipulate database objects, which users should connect to the database and how etc.
You may not need to put in place an entire monitoring stack, but knowing what some of the metrics on your database dashboard mean can be a valuable debugging tool.
You don't need to be an expert data modeller (although, as you saw, I think it's great fun) but as a minimum know how to read an ERD because it gives you a vision of the data in your system and how everything fits together. That shapes how you write code that accesses and updates that data.
Hopefully, someone else will be responsible for 24/7 support (especially if you're using a managed service) but being able to do some basic database troubleshooting could save you a lot of time
- debugging connection errors,
- figuring out why the database went down,
- understanding why performance of a certain query suddenly dropped off a cliff.
If a particular query or part of your application is performing badly, you want enough knowledge to be able to investigate and to be able to make improvements to performance. Of course, learning how to write code that performs well against the database in the first place is another essential
There's no getting away from data protection/GDPR. It's not a DBA-specific task, but it's tightly related to the database, and it's everyone's responsibility to make sure the rules are followed.
Going back to the list of DBA skills and capabilities: which of them to you actually need?
SQL, SQL, SQL.
I know, I know, everyone uses ORMs. Or AI. Or both.
But if you want to understand what the ORM or your AI tool is doing, and potentially why a query seems to be misbehaving, there’s no better way than to understand and to be able to write your own SQL queries.
And at least one person agrees with me. I saw that Jan Smitka was giving a talk called Faster Django ORM queries for everybody during the same conference, where he promised to talk about "N+1 queries, creating and using database views from Django, database indexes and EXPLAINing queries".
You don’t need to know about lots of different database technologies - just the one that you’re actually using. Obviously, I’m going to recommend Postgres for pretty much any situation, but you might have your reasons for using something else.
I already included performance tuning and disaster recovery in the responsibilities slide.
DevOps/automation is really important for keeping databases running smoothly, but I imagine you already know at least as much about DevOps and Automation as the average DBA.
And having spent time with the Python community, I know you’re OK on the social skills front!
If you don’t have the time, skills, inclination or infrastructure available to do all of the things you need to do to look after a database, there are options such as managed database services, that will do it all for you.
I worked for the Postgres company Crunchy data until June last year, when we were acquired by Snowflake.
Crunchy Data has a very popular managed Postgres service called Crunchy Bridge [14], and we launched Snowflake Postgres [15] at the beginning of this year, bringing Postgres to a whole new audience, which is really exciting.
This isn't a sales pitch, so I will say that "other managed Postgres services are available": You can go to any of the big cloud providers, and many smaller vendors, so you have plenty to choose from.
Even if do you have the skills and the inclination, it might just be a better use of your time and expertise to outsource some of these tasks.
One really handy postgres thing to know about is the extension ecosystem. There are Postgres extensions (essentially run-time patches) for everything from vector searches to geospatial, time series data, distributed databases, obscure index and data types, and almost anything you can think of to tailor Postgres into the specialist tool of your choice.
Some extensions are bundled with Postgres, some are developed independently by the Postgres community, others are proprietary. You're free to create your own if you want to, and share them (or not) with other Postgres users.
A list of just some of the hundreds of Postgres extensions that are available:
- pg_stat_statements Query history and analysis
- pg_vector Vector datatype, IVflatt and HNSW indexing and vector searches
- postgis Geospatial data types and functions
- fuzzystrmatch Phonetic matching (Soundex, Metaphone).
- postgres_fdw Foreign data wrapper to connect to other Postgres instances.
- hstore Simple key-value storage.
- uuid-ossp Functions to generate UUIDs.
The specific extension I think's really exciting at the moment is pg_lake [16][17] (although I recently became part of the team that's developing it, so I may be a bit biased.) It grew out of Crunchy Data Warehouse and was open-sourced by Snowflake in Nov 2025.
Postgres isn't a natural analytics engine, but the pg_lake extension lets you use Postgres to query, manage and write Iceberg tables and raw data-lake files (Parquet/CSV/JSON in S3) from within Postgres using plain SQL.
Postgres acts as the Iceberg catalog, so you have full transaction semantics, and it delegates to DuckDB where it needs to.
It's useful to know it exists as an option for the "my operational data is in Postgres but I also need analytics." use-case. It lets you do analytics on lake data without building ETL pipelines or a separate warehouse.
You can get a good idea of what I think it’s useful for you to know about databases by looking at the talks I’ve presented at developer events [18]. As well as "How to keep your database happy", there's:
- How to tune PostgreSQL to work even better (the most impactful config parameters)
- Tuning your database for Analytics (how to manage mixed OLTP/OLAP workloads)
- Everything you wanted to know about databases but were too afraid to ask your DBA (from instances and databases to tables, views and indexes, to connect strings and everything inbetween)
- Database troubleshooting for developers (how to recognise and fix the most common issues you’ll come across)
- Anatomy of a database operation (what happens when your app sends a query to the database)
- Partitioning best practices (the how, what where, when and why of partitioning database tables)
Where to find more information:
- PostgreSQL Documentation
- Conference talk recordings
- PostgreSQL Conferences
- PGConf.EU in Valencia this October
- Tutorials, e.g. Crunchy Data Postgres Playground
- Books, podcasts, blogs
At the risk of sounding like a broken record - you don't need to know everything about databases.
- Know that the concepts and techniques exist.
- Know where to look and who to ask when you need help or just more information.
- Learn just enough to make you successful in the things that are actually in your remit.
- Know enough to be able to tell when the tools (ORM, AI etc.) are doing something wrong.
If later you think "I vaguely remember Karen said something about that," I feel as though I've done my job.
I'm going to send you away with homework, sorry, an action plan!
In the next few days, try just one of these things:
- Review the value of one or two of your database's key configuration parameters
- Write one SQL query by hand instead of reaching for the ORM (or AI). In "the human in the loop is tired" earlier, Laura Summers gave us permission to just write the code; I'm giving you permission to just write the SQL.
- Go and see (or watch the recording of) Jan Smitka's "Faster Django ORM queries for everybody". (Jan was in the audience, so I let him know he could either thank me for inspiring folks to come along, or blame me if I scared everyone off!)
- Bookmark the Postgres docs so you can refer to them when you want more info.
- Pick one database talk to watch - there are lots of very interesting and clever folks who talk about Postgres.
- If you're exploring analytics on Postgres, try pg_lake and come back and tell me how it goes.
And then, hopefully, you'll soon be able to tell your friends "how I learned to stop worrying and love the database" (with sincere apologies to Dr Strangelove).
Thank you for reading!
Get in touch, or follow me for more database chat:
LinkedIn: https://www.linkedin.com/in/karenhjex/
Mastodon: @karenhjex@mastodon.online
Bluesky: @karenhjex.bsky.social
References
[2] https://www.statista.com/chart/28802/childhood-aspirations-in-china-us-uk/
[3] https://www.moneypenny.com/us/resources/blog/what-did-you-want-to-be/
[4] ttps://www.reed.co.uk/career-advice/revealed-what-your-kids-really-want-to-be-when-they-grow-up/
[5] Boyce-Codd normal form: https://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
[6] Transaction isolation levels: https://www.postgresql.org/docs/current/transaction-iso.html
[7] Daniele Procida, ”The Attentive Programmer” https://www.youtube.com/watch?v=_kKrKSfLj6E
[8] https://nationalcareers.service.gov.uk/job-profiles/database-administrator
[9] https://www.oracle.com/database/what-is-a-dba/
[10] https://www.prospects.ac.uk/job-profiles/database-administrator
[11] https://www.indeed.com/career/database-administrator
[12] https://www.itjobswatch.co.uk/jobs/uk/dba.do
[14] Crunchy Bridge: https://www.crunchydata.com/products/crunchy-bridge
[15] Snowflake Postgres: https://www.snowflake.com/en/product/features/postgres/
[16] pg_lake code: https://github.com/Snowflake-Labs/pg_lake
[17] Introducing pg_lake: https://www.snowflake.com/en/blog/engineering/pg-lake-postgres-lakehouse-integration/
[18] Karen's talks: https://www.youtube.com/watch?v=PsxNhcBTrTU&list=PL0IpRBoeAG2MrhwrFbDcu7W2LK9QN8dbE
Image Credits
Engineer: This_is_Engineering on Pixabay
Astronaut: pencil parker on Pixabay
Vet: jacqueline macou on Pixabay
Footballer: Joshua Choate on Pixabay