Zero downtime: Franck Pachot’s ‘migration’ from Oracle to PostgreSQL

Listen on:

We catch up with Franck Pachot, a longtime database community figure who has moved through Oracle, CERN, Yugabyte, MongoDB and, most recently, the PostgreSQL team at Microsoft. 

Hear stories from Franck’s varied career, learn what makes technical content genuinely useful to developers, how PostgreSQL’s MVCC and extension model differs from Oracle’s, and what’s really going on with Microsoft’s growing family of PostgreSQL offerings (Flexible Server, Horizon DB, and DocumentDB). 

Find Franck’s written content at https://franckpachot.github.io/pages/ 

Listen or watch to every episode of the Redgate Simple Talk podcast at 
https://www.red-gate.com/simple-talk/podcasts/

10 key takeaways from this episode

Don’t have time to listen? Here are the 10 key takeaways from this Simple Talk podcast episode with Franck Pachot.

1. Community involvement can quietly reshape a career

Franck Pachot traces the start of his broader database career back to a chance introduction at Oracle OpenWorld in 2014 (before he was even an Oracle ACE). That one connection opened the door to years of community involvement, which eventually gave him the confidence and network to explore databases beyond Oracle.

2. Curiosity drove his platform-hopping

Franck is clear: leaving Oracle wasn’t about disliking it. It was more a case of wanting to learn other systems but lacking the bandwidth to do so while consulting full-time. A move to CERN, with its variety of database technologies, was Franck’s first real opportunity to branch out.

3. Great technical content meets people at their level

Both Franck and host Kellyn Gorman point to Tom Kyte as a model for developer-focused communication, someone who explained why an answer was correct with a clear demonstration. Franck tries to build every one of his tutorials, articles, or demos, around that principle: simple, practical, and rooted in what the user is actually trying to do.

4. Understanding developers makes for better DBAs

Franck never wanted to be “the DBA who thinks developers are there to break the database.” Instead, his goal has always been to understand what the user is trying to accomplish and help them get there. It’s a mindset he carried through his advocacy work at MongoDB all the way to his present PostgreSQL role at Microsoft.

5. PostgreSQL’s MVCC isn’t worse than Oracle’s…it’s just different

Engineers coming from Oracle often assume PostgreSQL’s multi-version concurrency control (MVCC) – and its need for vacuuming – is a weaker design, but Franck firmly disputes this. PostgreSQL keeps all visibility information in the table tuples rather than the index – a deliberate trade-off that enables a much wider variety of index types and extensions, and is something Oracle’s single-index-type approach doesn’t allow.

6. “Free” open-source still comes with real responsibility

Both Franck and Kellyn emphasize that choosing PostgreSQL means taking on more ownership. With a commercial vendor, you can escalate a support ticket. With open-source, however, the responsibility for care, feeding, and decision-making stays with you. As Franck put it: it’s not free, but you have the freedom – and with freedom comes responsibility!

7. Microsoft’s PostgreSQL portfolio has three distinct flavors

First we have PostgreSQL Flexible Server, which runs standard community PostgreSQL (with extensions like Citus for sharding). Then, there’s Azure Horizon DB (in preview), which uses disaggregated storage to scale compute and storage independently (similar to Amazon Aurora or Neon). Finally, Amazon DocumentDB is a NoSQL/document layer built as a PostgreSQL extension, offering MongoDB API (application programming interface) compatibility on top of PostgreSQL.

8. Choosing a scaling strategy depends on your workload shape

Citus works well when you already know your sharding key – ideal for multi-tenant SaaS (software-as-a-service) applications. However, for workloads with multiple valid ways to query the data, Horizon DB’s storage-layer scaling may be a better fit, since it avoids picking a single sharding key up-front. This matters, especially when modernizing from SQL Server or Oracle.

9. The rise of PostgreSQL is actually the rise of “many PostgreSQL”

Franck notes the irony that companies want to standardize on “just PostgreSQL” to reduce database sprawl, but end up running multiple flavors of the system anyway! A fork for managed services, for example, or an extension for document workloads – the list goes on. The common thread, and what actually matters for developers, is that the SQL API stays consistent across all of them.

10. Build “T-shaped” expertise: deep in one area, broad everywhere else

Advice for newcomers to the database industry? Franck recommends developing deep expertise in one database, while maintaining a broad awareness of others. Not only does this help to learn new systems faster, it also allows engineers to understand the boundaries of their own knowledge – and know when to bring in outside expertise.