U.S. Bars and Pubs Database 2.0.0

Finding one place to have a drink is easy. Working with thousands of locations takes a consistent file, a clear definition of each row and enough context to judge whether the data fits your project. Version 2.0.0 of the U.S. Bars and Pubs Database contains 97,738 venue locations across the 50 states and Washington, DC.

The directory focuses on establishments primarily serving alcoholic beverages for consumption on the premises. Bars, pubs, taverns, beer gardens and nightclubs fit that scope. Restaurants whose primary business is meals and stores selling packaged alcohol for consumption elsewhere do not. Keeping that definition focused makes the data more useful for bar-specific research and planning.

Each row represents one listed venue location. The locations were reported open in the source snapshot used for this release. That is a useful selection rule, but it does not promise that every venue is open today. Businesses change names, move, close and reopen. Treat the file as a dated starting point and verify individual locations before making a time-sensitive decision, contacting a business or presenting an address to customers.

What comes in the package

The release has one Venues table with 43 fields. Eighteen describe the current source snapshot. One field describes historical match status, and 24 fields carry historical values where a unique match to the previous Oddity release could be confirmed. Current facts and historical context stay separate, so you can use the current fields alone or examine the added history where it exists.

The same validated population is supplied in CSV, JSON and SQLite. CSV works for a spreadsheet, import tool or reporting pipeline. JSON suits applications and scripts that expect structured records. SQLite provides a single database file you can query locally without setting up a database server. Choose the format that fits the tools you already use.

Supporting files include a schema, field dictionary, documentation, full-release statistics and 100-record samples. Samples help you check an import and inspect the structure. They are too small to estimate coverage or field completeness. For those questions, use the full-release statistics and the data itself.

Real-world place data is uneven. One location may have a complete address while a contact or descriptive field is blank. The public field table reports Distinct and Missing counts from the full release, including null values and blank strings as missing. If your workflow depends on phone numbers, coordinates or a particular detail, inspect that field's measured completeness before relying on it.

Using the directory

A regional analyst might group venues by state or city. A developer might use coordinates and addresses for an internal lookup. A researcher could compare this snapshot with another permitted source to investigate change. A business serving the hospitality industry might use it for territory planning. In each case, the file gives you a consistent starting population and an inspectable schema; you still need to decide whether the fields support your particular question.

Location counts are not market totals. The 97,738 rows are the locations selected for this release, not a census of every qualifying establishment in the United States. Coverage depends on the source snapshot and selection rules. An area with fewer listed venues may reflect source coverage as well as real differences. Use independent checks before drawing conclusions about market share, growth or local availability.

The directory is place data, not an endorsement or rating. Inclusion means a record met this release's scope and validation checks. It does not mean Oddity inspected the premises, recommends the business or guarantees its services.

Historical context

The earlier Oddity archive contributes history only where a current venue could be uniquely corroborated. That produced 7,611 matches. The match required the same normalized business name, address, city and state, plus a matching five-digit ZIP code or ten-digit phone number. Ambiguous and uncorroborated pairs were excluded. The older unmatched listings were not carried into the customer release.

The 24 legacy-prefixed fields on matched records are labeled historical_unverified. They provide context rather than fresh observations. A venue without a historical match is not necessarily new; it may have been absent from the earlier archive or lacked enough evidence for a confident match. If you compare older and current values, consider changes in the business, source coverage and recording methods before describing a trend.

Choose rights for your work

Usage Rights cost $50 and cover internal organizational research, operations, development and decision-making. Publication Rights cost $100 and also permit customer-facing websites, apps, reports and client projects without bulk dataset handoff. Master Rights cost $200 and also permit raw or transformed dataset handoff within a genuine client project. Standalone dataset resale requires a separate addendum.

Choose a tier based on what your work will produce and who will receive it. The package includes its applicable license files. Review the public samples, schema and field statistics for the columns you need, then select the format and rights that fit your workflow. A large row count is useful context, but the field detail will tell you whether this release answers your question.

How to read the field statistics

A field can look useful in a sample while being absent from much of the full file. That is why the public statistics report both the number of distinct nonempty values and the number of missing values for every published column. For example, the venue name field has 83,241 distinct nonempty values and no missing values in the 97,738-row release. The brand name field has 1,566 distinct nonempty values, while 92,433 rows have no value. That gap is normal for a directory with many independent businesses; it also means brand name is a poor substitute for venue name in a general lookup.

A distinct count is not a count of businesses. Two separate locations can share a name, and one location may appear under a chain or brand name used elsewhere. Likewise, a missing value does not necessarily mean the fact is unknowable. It means that the value is absent from this particular release field. When you need a unique place identifier, use the documented venue ID and the other location details instead of treating a name as a key.

The address and city fields deserve the same practical reading. A missing street address can make a record unsuitable for routing or customer display even when it remains useful for broader geographic analysis. A city name alone may be shared across states. Combine fields carefully and validate your matching logic against actual rows. If you are building a map, inspect coordinate completeness and plausible ranges before plotting; a point on a map can look authoritative even when the underlying location needs review.

The release covers all 50 states and Washington, DC, but that does not make every local market equally complete. One source may describe a downtown area more densely than a rural county. A city boundary can also affect how locations are labeled. When comparing areas, report the snapshot date and the selection rule, and consider whether a second source or local check is needed. That discipline matters especially when a count could influence spending, staffing or a public claim.

You can make the file more useful by choosing a verification routine that matches your purpose. For an internal exploratory dashboard, keep the vintage visible and flag fields with substantial missingness. For a customer-facing directory, establish a way to correct stale listings and confirm important details before display. For outreach, review whether your proposed contact use is permitted and whether each contact field is actually present. These are ordinary steps in responsible data work, not hidden limitations of this particular package.

Version 2.0.0 is a fixed release. Buying it gives you the validated files for this version under the selected rights, rather than a live feed that changes silently. That makes analysis reproducible: colleagues can inspect the same record population, schema and statistics. When a newer public version becomes available, it is a separate release with its own purchase or offered update. Keep the version number with any derived work so you can explain which snapshot it came from.

The sample files are a good first stop. Open them in your intended tool, confirm character encoding, inspect column names and test a few queries. Then compare the public statistics with the fields central to your project. If the structure and measured completeness meet your needs, use the full files and documentation to build the workflow. If they do not, you have learned that before trying to force the directory into a job it cannot support.