Announcement

New LTS for FreeBSD is now available in an initial release  Learn More

Klara
Emergency Help
Use case · Databases

ZFS storage tuned for production databases

Klara tunes OpenZFS for PostgreSQL, MySQL and other database workloads: recordsize, sync writes, SLOG and caching, set for your engine without giving up crash safety.

Talk to an engineer
Book a performance audit
Built on
  • OpenZFS
  • FreeBSD
  • Linux
Who it's for
  • DBAs and SREs running PostgreSQL or MySQL on ZFS
  • Teams seeing slow commits or latency spikes under write-heavy load
  • Platform teams moving databases onto ZFS who want it set up right the first time
File and folder icons streaming as light trails down a data-center aisle
Common ZFS database problems

Why databases need a tuned ZFS setup

ZFS defaults are built for general-purpose files. Databases write differently: small pages, mostly synchronous, and very sensitive to latency on the commit path.

Slow commits and sync write latency

Databases flush almost every write synchronously. Without the right pool layout or a fast SLOG device, every commit waits on the slowest disk and the application feels it.

Recordsize that doesn't match the page size

ZFS defaults to a 128K recordsize, while PostgreSQL writes 8K pages and InnoDB 16K. The mismatch multiplies every write and wastes ARC cache.

"Fast" settings that aren't crash safe

Turning off sync writes or full-page writes because a forum suggested it can leave a database one power loss away from corruption.

How Klara helps

The services behind this solution

Each links to the full service page.

ZFS

ZFS Performance Audit

A ZFS performance audit for database hosts in production. We measure the commit path, ARC hit rates and disk latency, and give you a ranked list of fixes.

→
ZFS

ZFS Storage Design

Pool layout, SLOG and drive selection planned around your database engine, page size and write pattern.

→
ZFS

ZFS Bug Investigation

When a stall or slowdown turns out to be in ZFS itself, our engineers trace it to the root cause and patch it.

→
Support

ZFS Developer Support

Direct access to OpenZFS engineers for your DBA and platform teams.

→
How a ZFS database engagement works

From audit to handover in three steps

1

Audit your database storage

We look at your database engine and version, page size, write pattern, pool layout, drives and RAM, then find where the latency on the commit path actually comes from.

2

Tune ZFS for your database

We set recordsize, logbias, compression and caching per dataset, add or resize the SLOG where it helps, and keep every change crash safe.

3

Benchmark and hand over

We measure before and after on your real workload, walk your team through the results, and leave documentation that explains why each setting was chosen.

Go deeper

Additional Resources

On-demand webinar

Database Performance on ZFS: Tuning for Latency and IOPS

Watch now

Article

Safe ZFS Tuning Practices for Production Databases

Read now

Article

Managing Cache and DirectIO for Databases on ZFS

Read now

Get started

Get your database storage reviewed by ZFS engineers

Tell us what you run and where it hurts. Our teams have a 72h response time, so someone will reach out shortly.

Production down right now?

Get Emergency Help