{
  "id": 1666687,
  "title": "Building a real-time global leaderboard with Supabase Realtime",
  "url": "https://urgent.news/2026/08/18/building-a-real-time-global-leaderboard-with-supabase-realtime",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-18T08:00:02.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/furiosastudio/building-a-real-time-global-leaderboard-with-supabase-realtime-4dkd"
  },
  "original_language": "en",
  "account": "Creating a real-time global leaderboard with Supabase Realtime presents a challenging task, especially when it comes to maintaining accuracy and performance under heavy load. The key to achieving this lies in a well-planned data model and efficient querying techniques.\n\nFirstly, the core data model consists of an append-only events table and a scores aggregate table. The scores table stores the user's total score and a timestamp, ensuring that the data remains consistent and easily updatable. An index on the total column, ordered by total in descending order, allows for efficient retrieval of the top N scores without the need for sorting or a window function. This index is crucial as it enables quick access to the leaderboard data, making it possible to retrieve the top ranks without a costly sort operation.\n\nTo compute a user's rank without scanning the entire table, which would be inefficient during peak loads, a window function is used. This approach, `rank() over (order by total desc)`, efficiently assigns ranks based on the score without requiring a full table scan. For a user who wants to know their rank (e.g., rank 48,201), the query counts the number of users with a total score higher than theirs, thereby determining their position in the leaderboard. This method is both efficient and scalable, as it avoids the need to paginate through the entire leaderboard.\n\nWhen considering the volume of reads versus writes, particularly in a scenario where the global leaderboard is accessed far more frequently than it is updated, a materialized view proves to be a valuable optimization. This view can be refreshed on a schedule or updated in real-time using a trigger. By refreshing the materialized view concurrently, it ensures that read operations never block other operations, providing a seamless experience for users. The maintenance and refresh of the leaderboard are handled in a way that prevents the full table from being scanned every time a read is requested, thus maintaining the performance of the application.\n\nWith regard to pushing updates to clients, Supabase Realtime offers two options: `postgres_changes`, which emits a message for every affected row, and `broadcast`, which is a lightweight pub/sub channel used to send already-computed payload updates. For a global leaderboard that requires only the top 100 scores, using the `broadcast` channel is more efficient. It reduces the number of messages sent over the network and avoids the chattiness associated with `postgres_changes`. The trigger or edge function recomputes the affected slice of the leaderboard and broadcasts the result, which is then received by all subscribed clients. This method ensures that each client is only updated with the changes relevant to their view, keeping the system efficient and responsive.\n\nThe UI can be enhanced with an optimistic update strategy, where the user's score is immediately adjusted locally upon their action, and the authoritative update is applied once the server confirms the change. This approach makes the application feel instant to the user, as they see the results of their actions immediately. Once the broadcast from the server updates their rank, the UI is reconciled to reflect the correct score. This local-optimistic approach ensures that the application remains snappy, while the eventual consistency model ensures that the server's authoritative data is always the source of truth.\n\nWhen dealing with concurrent writes, such as in a global leaderboard scenario, it's important to avoid overloading the system by recomputing the leaderboard on every event. Implementing a debounce mechanism, which defers the execution of the recompute function and limits it to occur once every few seconds, helps in reducing the computational load. Additionally, only recomputing the ranks affected by the most recent score updates further minimizes the workload on the database. By combining these strategies with the efficient use of materialized views and the broadcast channel, the leaderboard can remain highly performant even under heavy concurrent usage.\n\nIn summary, by designing a data model that emphasizes simplicity and efficiency, utilizing advanced querying techniques with window functions, and employing a smart broadcasting strategy with Supabase Realtime, it's possible to build a real-time global leaderboard that is both fast and scalable. This approach ensures that users see the most up-to-date leaderboards in near real-time, while also keeping the database operations light and manageable. This methodology not only solves the practical challenges of building such a system but also demonstrates the power of leveraging modern database technologies to create performant and user-friendly applications.",
  "summary": "A leaderboard looks trivial until it has to be live, global, and correct under load: rank the world by score, push every change to every connected client, and never melt the database doing it. Here's a pragmatic architecture for exactly that, built on Postgres and Supabase Realtime. The data model Keep the source of truth boring. One append-only events table for every scored action, and a scores…",
  "key_points": [
    "Use an append-only events table and scores aggregate table for consistency.",
    "Compute rank using window function without full table scan.",
    "Broadcast top 100 scores to clients for real-time updates."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}