Count(*) vs Count(1) in SQL

By Vishal BarvaliyaLast updated
Count(*) vs Count(1) in SQL

If you’ve spent any time writing SQL queries, you’ve probably seen both COUNT(*) and COUNT(1) used to count rows in a table. But what’s the difference between them, and which one should you use? Let’s break it down.

Let's discuss COUNT(*) and COUNT(1) in SQL. You've probably seen both used to count rows in a table, but what's the difference, and which one should you use?

What They Do

  • COUNT(*): Counts all the rows in a table, regardless of NULL values or anything else. It simply tallies up the total number of rows.
  • COUNT(1): Also counts all the rows, but does so by counting the number of times the literal value 1 appears in each row. It’s like saying, "Count every row where 1 is present."

Performance Talk

In terms of performance, there's usually not much difference between the two. Modern databases handle both efficiently. While some argue that COUNT(1) might be slightly faster in older databases due to counting a constant value, the performance difference is typically negligible.

Readability Matters

Readability is crucial. When you see COUNT(*), it’s immediately clear that you're counting all the rows. It’s straightforward and easy to understand. On the other hand, COUNT(1) might cause a moment of confusion since it’s less obvious that it’s counting all rows.

Final Thoughts

So, which one should you use? It largely depends on personal preference and your project's coding standards. Both COUNT(*) and COUNT(1) are effective, but COUNT(*) is generally preferred for its clarity and readability.

Ultimately, choose the one that makes the most sense to you and your team. As long as your SQL queries are easy to understand and maintain, you’re in good shape.

Keep reading

More posts tagged “Community”.
What are Connection Pools and How Do They Help with PostgreSQL?

When you're building an application that interacts with a database, you’ll often need to establish a connection to the database each time your application wants to retrieve or store data. This can be slow and resource-intensive, especially if your application needs to interact with the database frequently. This is where connection pooling comes in.

Tue, Sep 17, 2024
Stop Using UUIDs in Your Database

How UUIDs can Destroy Database Performance

Thu, Jul 11, 2024
Simply Rely on Postgres for All Your Needs

Replace all your infrastructure with one simple database

Tue, Jul 9, 2024
Redis Alternatives 2025

Redis is usually chosen as a cache because of its speed and versatility, allowing developers to provide users with a faster and smoother experience. But after its license change, many companies are looking for an alternative. In this post, we will take a look at the most popular options for replacing Redis as a cache.

Fri, Jan 10, 2025
Fly vs Railway vs Render: deploy costs compared 2026

For solo technical founders launching an MVP on a tight budget, Railway offers the lowest entry cost and fastest setup, while Granite provides a compelling all-in-one alternative with integrated storage and CDN for a predictable $9/month—making either a better starting point than Fly.io or Render for most early-stage projects.

Fri, Mar 27, 2026
Heroku vs Granite: PostgreSQL pricing and limits in 2026

This article breaks down how Heroku's PostgreSQL pricing and limits compare to Granite in 2026, with enough detail for you to make a real decision in the next hour.

Tue, Mar 31, 2026
Be first in line for updates
and special pricing
Get early access to new features and exclusive discounts delivered straight to your inbox