About Gold Lapel
A proper introduction is in order. Do take a seat.
The premise
Good evening. Allow me to explain what we do here.
Your database already knows a great deal about what is slow. It collects statistics, produces execution plans, and records wait events. It knows which queries scan entire tables when a well-placed index would suffice. It knows which joins compute the same result thousands of times per hour.
What it lacks is the initiative to act on that knowledge without someone asking.
Gold Lapel was built on a single conviction: your database should optimize itself. Not after a performance review. Not after a P1 incident. Not after an engineer spends a Thursday afternoon reading EXPLAIN output. Automatically, continuously, and from the moment you connect.
What Gold Lapel does
Gold Lapel is a self-optimizing PostgreSQL proxy. It sits between your application and your database — observing every query, identifying patterns, and attending to each one with the discretion it deserves.
It creates materialized views to precompute results. It adds indexes where filters would benefit. It rewrites queries to use faster execution paths when they exist. Your application sends the same queries it always has. The responses simply arrive rather more promptly.
I should note: Gold Lapel never modifies your data, never changes your schema in ways you cannot inspect, and invalidates caches the moment a write is detected. It is, if you will permit the description, a waiter for your database — attentive, transparent, and discreet.
Cache invalidation, handled
The hardest problem in caching is knowing when to stop serving the cached answer. Most caching layers leave this to you — write your data, then remember to invalidate every key that might be affected. Miss one, and your users see stale results. Build it correctly, and you are maintaining a parallel system of invalidation logic that grows with every table, every relationship, every edge case. It is, I am afraid, the sort of housekeeping that never ends.
Gold Lapel sees every write as it passes through the proxy. When an INSERT, UPDATE, or DELETE touches a table, every cached result that references that table is invalidated automatically. No keys to name. No TTLs to estimate. No invalidation calls scattered across your codebase. The cache is always current because the system that fills it is the same system that watches the writes. Every query is served by the nearest accurate cache layer — PostgreSQL is only troubled when necessary.
Three tiers of optimization
Gold Lapel builds and maintains a continuously updated caching layer using your existing PostgreSQL infrastructure:
An in-process cache within your application. No network round-trip. Repeated reads serve directly from memory. Writes invalidate cache instantly.
An in-memory cache within the Gold Lapel proxy. A single TCP hop. Serves cached results when L1 has not yet seen the query.
Precomputed query results stored in PostgreSQL itself. Full SQL semantics, continuously refreshed. The optimization that makes even a cache miss fast.
All writes go to PostgreSQL. All cache layers invalidate from PostgreSQL. When a write is detected, all cache layers invalidate and reads route to the most current source available.
How to use it
Install the package for your language. Call gl.start() with your database URL. Pass a configuration object, to taste. That is the extent of the disruption.
Gold Lapel works with every language, framework, and ORM that speaks PostgreSQL. Your queries stay exactly as they are. Gold Lapel learns what matters by watching what you actually run.
One does not rush a proper introduction — but one does know when to conclude it. If you would like to see Gold Lapel attend to your queries, the documentation awaits. If you would prefer to ask questions first, so do I.
Questions, feedback, or simply a query that needs attention: thewaiter@goldlapel.com