Replace auction_orders table with index on order_uids column

[MartinquaXD]

Description

When I investigated some of the fallout of the recent DNS issues I noticed that the post-processing that happens in the autopilot run loop (storing important bookkeeping information in the DB before telling the winner to /settle) can be very slow. The biggest offender was the save_auction call that first writes into competition_auctions and then into the auction_orders table. This currently routinely takes 250-500ms according to our metrics.

However, it seems like the write into the auction_orders table is completely redundant as it duplicates the information we already have in competition_auctions::order_uids. The new redundant table was introduced in #4233 to quickly find all auctions that contained a given order uid. However, this can also be achieved using a GIN index on the existing order_uids table.

partially addresses #3057

Changes

Create GIN index on competition_auctions::order_uids and update the code to use that instead of the auction_orders table. To not have anything break during the release the auction_orders table will be dropped in the release after that to make sure no pods are using the old table during the rollover.

How to test

I cloned the prod DB and created the new GIN index. While it took ~6.5h and 12% CPU usage the resulting index was significantly smaller than the deprecated table + index (20GB vs 470GB) and the new queries were actually faster on the new index.

migration (6.5h @ 12% CPU)

size comparison (19GB vs 492GB)

query performance (77ms vs 147ms)

and as a last sanity check I also compared the data of the 2 tables and since the competition_auctions table was created before the auction_orders table it even contains 6 times as much data.

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).

• If creating new tables, update the tables list.
• When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.
• For breaking changes, remember that during rollout k8s starts the new autopilot, runs the Flyway migration, and only then shuts down the old pod. That overlap means the previous version can still be processing requests on the migrated schema, so make it compatible first and ship the breaking DB change in the following release.

---

Caused by:

• database/sql/V112__gin_index_orders_in_auction.sql

[github-actions]

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.

[claude]

Claude finished @MartinquaXD's task in 2m 6s —— View job

---

PR Review: Replace auction_orders table with GIN index

• Read changed files & gather context
• Analyze migrations, DB queries, and code changes
• Post inline comments for any issues
• Post review summary

Nice change — the GIN index is a clean replacement and the code cleanup is straightforward. The new @> query is functionally equivalent to the old junction-table lookup and the removal of save_auction_orders from the hot path is a good win. Two blocking issues to address, posted inline:

1. Migration version collision (blocker) — main now has V111__drop_pool_indexer_uniswap_v3.sql, so this PR's V111 is a duplicate and Flyway will refuse to start. Renumber to V112/V113. details
2. Rollout safety of DROP TABLE — the old autopilot still writes to auction_orders during the rolling-update overlap, so the drop should ship in a following release (per the CI reminder). details

No other issues — the README, LARGE_TABLES, and debug-skill updates all look correct and consistent.

[gemini-code-assist]

Code Review

This pull request removes the redundant auction_orders table and replaces it with a GIN index on the order_uids column of the competition_auctions table, updating the database queries, schema, and documentation accordingly. Feedback highlights a critical deployment issue: creating the GIN index on production takes approximately 6.5 hours, which will exceed the 5-minute deployment limit and cause the automated Flyway migration to fail. To prevent this, the index must be created manually on the production database prior to deployment.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

According to the database/README.md guidelines, migrations that require a long-running process must be executed manually because the weekly release process imposes a 5-minute deployment limit (and a 600-second pod deadline). Since creating this GIN index on the production database takes approximately 6.5 hours (as noted in the PR description), running this as an automated Flyway migration during deployment will cause the release to time out and fail.

To prevent deployment failure, this index must be created manually on the production database prior to deploying this release. Once created manually, the IF NOT EXISTS clause will allow the Flyway migration to complete instantly during deployment.

[jmg-duarte]

🧹

[MartinquaXD]

Since opening the PR I already went ahead and created the new index on all tables - mainnet is still working on it but should be ready in the morning.
I also wanted to reproduce the results on the actual prod DB just as a last sanity check. That's when I ran into a wall for a while.
When originally testing the PoC the query I tested fetches all the auctions which reliably picked the new index for milliseconds results.
However, when I tested in prod I always tested with LIMIT 1 which ALWAYS triggered a squential scan which I aborted after 10s of seconds runtime.
Fortunately I was able to figure out what was happening. The issue lies in the "shape" of the auction and the specific order I picked. Auctions currently have ~3K orders on base and the vast majority of orders shows up in thousands of auctions because they are long standing limit orders. The order I picked was one that was evicted from the auction - either because it was settled or it expired. In other words I picked a super rare order.
Postgres keeps stats on common values and a rough estimate of unique values. Given that the vast majority of orders shows up in the vast majority of auctions it's a reasonable decision to do a sequential scan for searching 1 instance of a random order as that still beats the low constant overhead of using the GIN index.

So while it's not needed for this PR I want to spare others going through the same investigation as I did.
So if you really have to find a limited number of items, either return all as a stream and only take 1 item from the stream (i.e. solution in rust) or you do the unbounded query in a materialized CTE and only select 1 item from it (solution in SQL).

WITH matches AS MATERIALIZED (
  SELECT * FROM competition_auctions
  WHERE order_uids @> ARRAY['\x13f4...f5fb'::bytea]
)
SELECT * FROM matches LIMIT 1;