While reviewing the code behind OAS's website-status checks, we found a reader whose database work grew with each hosted site. It issued one initial SQL statement, then two additional statements per hosted site. Those repeated reads were easy to miss in a one-site fixture, but their count grew with each additional site.
What we measured
OAS's test suite runs against a real PostgreSQL 17 database that starts and stops with the tests. It counts every SQL statement the application sends. We built a synthetic business with ten hosted websites and counted.
The old reader sent 21 statements: one for the list of websites, then two more for each hosted site, one after another. It re-read the same business details every time, and then read that site's domain status. The new reader sends 2, whether the business has one website or ten.
These are statement counts from a controlled test fixture. They are not a production latency benchmark, and ten websites is a test size, not a typical customer.
Why the old path grew with every site
The reader worked one site at a time. To decide whether a site's live version was current, it rebuilt that site's configuration from the business's details. Each rebuild fetched those details again, along with the site's domain status. So a business with one site cost 3 statements, and each additional hosted site added 2 more.
What changed
The new reader asks for the business and all of its websites in one query. Our database library runs that as two SQL statements, one for the business and one for its sites, and the reader then works out each site's status in memory, with no database call inside the loop.
The rules did not move into a cache or a background job. The checks that decide whether a site can be published, and whether it is hidden from search engines, now live in one shared helper that both the publisher and the reader call. Publishing itself, and the record it keeps, did not change.
How we checked that nothing else changed
Fewer queries only counts if the answers stay the same. The test keeps a copy of the old one-site-at-a-time algorithm and compares the two readers across every state a site can be in: never published, not publishable, current, and changed. It covers a site after the business edits its details, after a design change, and after a domain goes live. The answers, the wording of each refusal and the order of the sites all have to match.
The same test runs the old algorithm beside the new one and asserts both counts: 3 and 21 for the old path at one and ten sites, 2 and 2 for the new one. A change that brings back a per-site query fails the test suite.
The fix was not another service. It was a better query boundary, with the same answers.
What the result proves, and what it does not
It proves that, for this synthetic ten-site business, the status check costs 2 SQL statements instead of 21, and that the number no longer grows with the number of sites. It does not establish a response time, a cost saving or anything about production traffic. We did not measure those, so we do not claim them.
The console now derives this status from website records it has already loaded; no application request currently calls the optimized reader. The two-statement result above describes the tested reader, not a measurement of the current production page. The original fix came out of a wider review of how the console reads the database.
If you run a contracting business and want to know how OAS keeps your customer information in one place, get in touch.