Polling the Database

Database polling means a process repeatedly runs a query — often on a fixed short interval — to check whether something changed: new rows in a queue table, a status that flipped, a job ready to run. It is the default way many systems detect change because it is simple, but at any scale it is wasteful and slow at the same time.

Why It Happens

Polling is the most obvious solution: loop, query, sleep, repeat. It needs no extra infrastructure and works the first day. Using a table as a job queue invites it. Teams unfamiliar with change-data-capture or the database's native notification features default to a SELECT in a loop because it is conceptually simple.

Why It Hurts

Polling forces a trade-off with no good setting. Poll often and you generate constant query load even when nothing changed, burning CPU, I/O, and connection-pool slots; many pollers create a thundering herd that hammers the same hot table. Poll rarely and you add latency, detecting changes seconds or minutes after they happen. Polling queries on a queue table often scan or lock rows, contending with the writers they are watching. The load is paid continuously regardless of whether there is any work to do, which scales badly as the number of pollers or tables grows.

Warning Signs

• A SELECT runs on a tight loop with a sleep between iterations.
• A fixed poll interval is tuned as a compromise between load and latency.
• Many workers repeatedly scan the same queue or status table.
• Database load stays high even during periods with no real activity.

Better Alternatives

Let the database or a log push changes instead of pulling. Change-data-capture streams committed changes from the transaction log to consumers with low latency and no polling load. Native database notification mechanisms (such as LISTEN/NOTIFY) wake a waiting client the moment a relevant change commits. For decoupled work distribution, an event-driven architecture with a real message broker replaces the queue-table-plus-poller entirely. These push models deliver lower latency and lower load simultaneously.

How to Refactor Out of It

Identify what the poller is watching for and choose a push mechanism: CDC for data changes feeding pipelines, notifications for in-database triggers, or a message queue for job dispatch. Wire producers to emit events on change and consumers to react, removing the polling loop. Where polling must remain for compatibility, widen the interval and use efficient skip-locked dequeues to cut contention. Measure the drop in idle query load and in change-detection latency to confirm the improvement.