Chun Lin Goh

About the Speaker

• Tell us about yourself: career, family, passions

  I am a Senior Cloud Architect from Singapore. I have been a member of the .NET Foundation since 2019. My career is mostly about "gluing" complex cloud systems together to make sure they do not break. Outside of work, I focus on open-source projects like SNA, the one I am sharing in this POSETTE talk. I like drawing anime too.

• What’s your favorite way to break the ice or start conversations at PostgreSQL events?

  I usually ask people: "What is the most expensive mistake you’ve seen in production?" It is the fastest way to skip the small talk and start sharing real technical "trauma" and lessons.

• What would you say is your superpower?

  I am good at seeing how different parts of a system, such as database, code, cloud, and observability, interact and fail together.

• Which book are you reading right now and why did you choose it?

  I am revisiting the Zhuangzi, specifically the parts about Xiao Yao You. It talks about Wuyong, or the "usefulness of the useless". In my career and life, I see this everywhere. People focus on being useful by chasing titles or working until they burn out. But I view my life like the "gnarled tree" in the book. By focusing on things that seem useless to others, such as deep-dive simulations or hobby projects, I actually build a more resilient path. This useless knowledge is what keeps me stable in the current world.

• What is your favorite hobby?

  Digital illustration and anime art. I have had my work exhibited in the Singapore Original Comics Festival. It is a creative outlet that balances the logic-heavy nature of my work in systems architecture. I also enjoy low-level programming on Commodore 64 because it is honest.

About the Talk

• Tell us about your talk? Why did you choose this topic?

  My talk is about the performance simulation on burstable cloud instances like Azure B-series. Many companies use them to save money, but they do not realize their database will "brick" when the CPU credits hit zero. I chose this because I would like to share how we can perform shift-left infrastructure testing with simulation instead of guessing.

• Who would benefit the most from your talk and why?

  Engineers and leads managing Postgres on cost-constrained cloud tiers. While the standard advice is to NOT use burstable instances for production, the financial reality for many companies is different. This talk is for those who need to maintain 99.9% availability while operating within those hardware limitations.

• What do you hope attendees will walk away with after watching your talk?

  I want attendees to see Discrete Event Simulation (DES) as a way to shift-left their infrastructure testing. Usually, we only find out issues after production crashes. By then, it is too late. I am showing how to test infra limits in code first, so we can validate our scaling and pooling strategies before a single server is even provisioned.

• Which talk at POSETTE 2026 are you most looking forward to? And why?

  I am looking forward to the "Postgres 19 Hackers Panel" and Andrew Ruffin's talk on "Choose the Right Azure Infrastructure to Improve Postgres Performance by Over 60%".

  Why? As a software engineer, I need to understand both the internal physics of the next Postgres release and the reality of the cloud hardware it sits on. One helps me manage technical debt, and the other helps me optimize for cost and performance. Seeing both perspectives is essential for building resilient systems.

• How do you balance technical depth with engaging storytelling in your conference presentations?

  I do not focus on storytelling. In a production crisis, engaging stories could be misleading. I focus on raw simulation data and identifying failure points.

About PostgreSQL

• What inspired you to work with PostgreSQL?

  Honestly, it was the rise of Generative AI and RAG. I needed a reliable way to handle vector embeddings, and pgvector made Postgres the most pragmatic choice. I stayed because I realized that instead of adding a complex new vector database to the stack, I could get the same results using the physics of a stable, long-standing engine like Postgres for my AI infrastructure.

• What is your favorite PostgreSQL feature, extension or tool? And why?

  My favorite is pgvector, but for a specific reason. As shared earlier, I came to Postgres because I needed a vector store for RAG and AI chatbots. But I realized that the real power is not just storing vectors. Instead, it is that you can use standard Postgres tools like pg_stat_statements to monitor them. I can use the same observability tools I already know to see exactly how my AI workloads are hitting the CPU and memory. It’s about having a stable foundation for new tech.

• What is the single thing that you think differentiates PostgreSQL most from other databases?

  It is the transparency. Most databases are a black box because when they fail, we just see a timeout. However, Postgres gives us the observability we need to actually understand the failure. This transparency is also the reason I can build a DES to predict its behavior.

• What advice would you give to someone starting their journey with PostgreSQL?

  Do not just learn SQL syntax. In this AI-enabled world, anyone can write a SELECT statement. My advice is to learn the physics of the database, such as the connection overhead, memory limits, and how the cloud hardware underneath impacts its performance. If you understand the limits early, you will not have to stay up all night fixing a production outage later.

• What are your favorite resources for learning about PostgreSQL?

  I mainly rely on PostgreSQL documentation and the technical blogs from the major cloud providers who host it. Because I started with pgvector for RAG, I spent a lot of time reading specific documentation for extensions and indexing strategies.

• Could you share a memorable experience or challenge you faced while working with PostgreSQL?

  The most memorable challenge was a project where I had to deliver a production-ready AI infrastructure using pgvector on a very tight timeline. I did not have months to study every Postgres internal. The challenge was not just the database, but also the pressure of making sure a system I was still learning would not fail under load. That experience is actually what led to the research I am sharing in my talk.

• In your opinion, what are the most common pitfalls or mistakes developers make when working with PostgreSQL?

  One of the biggest mistakes is treating the database as a black box with infinite resources. Many developers write code and design schemas without ever looking at the underlying cloud hardware. For example, they do not account for CPU credit depletion or I/O caps until the p99 latency explodes. They wait for a production disaster to happen before they realize their instance size was just a guess. To me, not simulating these failure points before you go live is the biggest pitfall in modern cloud development.

• Which skills are a must-have for a PostgreSQL user/developer?

  Beyond basic SQL, I think the three must-have skills are Observability, Resource Awareness, and Simulation.

  We need to know how to read execution plans and telemetry like pg_stat_statements so we are not flying blind. We also need to understand the underlying hardware limits like CPU credit limit. Finally, we need the skill to shift-left our thinking, i.e. being able to model and test our assumptions before they hit production.

• What is the most overlooked thing about PostgreSQL?

  The underlying hardware. Most developers treat Postgres as a data storage only. They overlook how the database interacts with cloud resource constraints like CPU credits and I/O throttling. Understanding that connection between the logical database and the physical cloud instance is one of the most overlooked parts of database reliability.

• PostgreSQL is opensource, did that ever help you in anyway and how?

  The biggest help is the lack of friction. As a developer in a fast-moving market like Singapore, I do not always have the time to wait for budget approvals or license keys. Because Postgres is open source, I can spin up an instance to prove a concept and demo before the company spends a single cent. Of course, it is not just about being free, but also with Postgres, the community builds features as soon as the need exists.

• If you had a magic wand, what single thing would you change in PostgreSQL as it is today?

  If I had a magic wand, Postgres would natively sense when it is being throttled by the hypervisor and reflect that in its wait events or telemetry. This would allow the database to make "aware" decisions.

• Are you involved in any volunteer or community efforts around PostgreSQL? If so, what do you do and why did you get involved?

  No, outside of my preparation for POSETTE, I do not participate in PostgreSQL community volunteering.

About POSETTE & Events

• Have you enjoyed previous POSETTE (formerly Citus Con) conferences, either as an attendee or as a speaker? If so, what did you enjoy most about it?

  I followed the 2025 sessions on YouTube. What stood out to me was the high signal-to-noise ratio. Most of the talks were focused on engineering reality rather than marketing fluff, which is exactly the kind of environment I value as a speaker.

• What motivated you to speak at this year’s POSETTE: An Event for Postgres?

  I want to bridge the gap between DES and the PostgreSQL community. In the industry, we often treat performance tuning as reactive, i.e. we wait for a bottleneck and then fix it. I am motivated to show how we can use DES to shift-left this process. By treating database behavior as a predictable system, we can identify performance issues before they happen in production. I am here to advocate for a more scientific, simulation-based approach to database reliability.

• What other PostgreSQL events in 2026 are you excited about and why?

  To be honest, I haven't looked into other PostgreSQL events for 2026 yet. My focus is entirely on POSETTE right now. Once this talk is delivered and I have seen the feedback, I will look at where that conversation needs to go next.

• What advice would you give to fellow speakers preparing for a PostgreSQL conference?

  My advice is to focus on technical honesty. Don’t just show the successful results. Instead, we show where the system fails. In this community, authenticity is more valuable than a polished marketing pitch.

• What would be helpful to know for a first-time speaker?

  As a first-time speaker, my advice is to prioritize internalization over memorization. Don't just read a script. You need to own the data. If you don't believe in the truth of what you are sharing, the audience will sense it immediately.

• Could you share a memorable moment from a previous PostgreSQL conference you attended or spoke at?

  As a first-time speaker, my exposure has been limited to the POSETTE 2025 online sessions. The most memorable thing for me was not a single moment, but the overall experience. The speakers gave me the confidence to share my own simulation research this year because POSETTE felt like a community that values reality over prestige.

Open Forum

• Is there anything you’d like to share with the Postgres community attending this year’s POSETTE: An Event for Postgres?

  As a first-time speaker, I am just really grateful for the chance to contribute to the community. I hope my session on simulation gives other engineers a new tool or a new way of working to prevent production issues before they happen. I am looking forward to learning from everyone else’s real-world stories in the chat!