Delicatessens Database 2.0.0: 58,714 U.S. Locations

A clearer map of deli and sandwich-shop locations

The Delicatessens Database is now at version 2.0.0. It contains 58,714 screened U.S. business locations across all 50 states and Washington, DC. The release keeps 43,774 sandwich-shop locations and 14,940 delicatessen locations separately classified. Those groups add to the location total; they are not extra businesses on top of it. The directory snapshot is dated September 23, 2026, so it is a documented point-in-time view rather than a promise that every storefront is open today.

That distinction matters when the data is used for territory planning, market research, an application, or a published report. A sandwich shop and a delicatessen can overlap in everyday language, but a project may need one category, the other, or both. The classification table lets users make that choice explicitly and retain the choice in a reproducible query. The total is a count of selected locations in this release, not a census of every U.S. business that might fit a broad definition of deli.

Four connected tables

The main locations table has 58,714 rows and supplies the stable location_id, business name, address fields, coordinates where available, primary category, reported status, and data-confidence information. The classifications table has 58,714 linked rows and keeps the published deli-versus-sandwich label alongside each location. Users can join it to locations by location_id and filter by category without treating a label as a second site.

The contacts table has 111,799 related rows. A location may have several reported contact channels, so this number is a count of contact records, not a count of businesses or confirmed people. The source_lineage table has 175,485 related rows and provides record-level provenance fields within the licensed package. Those lineage rows are also not additional locations. Keeping these details in separate tables makes it easier to inspect a business record, review its supporting information, and avoid inflating location totals when joining tables.

Join through location_id, then check the row unit before aggregating. For example, a count after joining contacts can be larger than the number of distinct locations because a business can have more than one contact record. When a map or report needs a site count, count distinct location IDs or start from the locations table. When it needs contact channels, count the contact rows and label that measure accordingly.

Choose the package for the work

The release provides CSV, JSON, and SQLite working files. CSV supports familiar inspection and import workflows, JSON fits structured application pipelines, and SQLite preserves the related tables in a portable database. The public product page includes the schema, table and column statistics, and sample material so a team can assess the structure before ordering. The signed full files remain behind the account's protected download flow.

The Usage package contains locations and classifications for internal work. Publication adds contacts and rights for customer-facing sites, apps, reports, and client projects under its terms. Master includes source_lineage and permits raw or transformed dataset handoff within a genuine client project under its terms. Standalone dataset resale is a separate matter. The current prices are $40 for Usage, $80 for Publication, and $120 for Master. Customers should read the exact current license before choosing a tier, especially when a workflow distributes results or data to others.

An account with an eligible earlier Master version may see a $10 current-version update offer. That is an account-specific version purchase based on recorded eligibility, not the price of a new Master license. The account portal shows the applicable offer and protected downloads. A customer who does not have earlier eligibility can choose the current tier that matches the intended use.

Read the dates and gaps with the data

A dated directory is useful because its scope can be explained. It still needs care. Businesses open, close, move, change names, and update their contact channels after a snapshot. Reported operating status and coordinates reflect the available records, not an independent real-time inspection. A contact value can be absent or stale; it is not consent to contact a person. Verify high-impact individual records against current information before outreach, site visits, routing, or public claims.

The published column profiles distinguish populated values from missing ones, including blank strings as well as nulls. Review them before designing a workflow that requires a particular field. A sample shows format and representative structure, while the full-release statistics describe the delivered population. If a downstream project adds newer evidence, keep that source and date separate from the original release so later comparisons remain understandable.

Practical ways to work with the release

A location planning team can begin with the locations table, filter the classification to the business type it actually wants, and then review the geography and confidence of the selected records. For example, a study of sandwich-shop footprints should say that it used the sandwich-shop category and should not quietly present the result as all delicatessens. A study that combines both groups should preserve their individual counts alongside the combined number. This makes a map or summary easier for another person to interpret and reproduce.

An application developer can import the SQLite file and use location_id as the stable join key within the release. The same relationship is available across the matching CSV and JSON representations. Before building a customer-facing search, inspect the fields that the application will expose, including missing values and reported-status limits. A record with no usable contact channel should still be handled gracefully. Search results should give users enough context to recognize that the directory has a snapshot date and that a listed business may have changed since then.

A researcher can compare distribution by state or category, but should define the unit of analysis first. Counting related contact or lineage rows as though each were a storefront will distort a geographic total. Likewise, the number of records in a chain should not be assumed to describe ownership, employment, sales, or current market share. Those questions require separately verified information. The release supports a location-level starting set and a way to inspect related fields; it does not answer every business question by itself.

For outreach planning, use the contact table as a lead for verification rather than a permission or deliverability guarantee. The presence of a website or phone number does not show that a particular person agreed to be contacted, that an inbox is active, or that a business has not changed hands. Check the current business, the chosen channel, applicable rules, and the purpose of the contact before using it. Record what was verified and when. The original licensed snapshot and a later verified contact layer should remain distinguishable.

Keeping updates interpretable

Version 2.0.0 is a distinct release, so save the version with exports and downstream analyses. If a future release adds, removes, or reclassifies a location, an old report can still be interpreted against the population it used. The stable IDs help compare records inside a release and support later comparison, but a match across dates should be checked when names, addresses, or source evidence change. A new count can differ because of coverage, screening, category definitions, or business changes; the number alone does not tell which occurred.

The documented source date provides a practical review schedule. A team using the data for a static historical analysis may need to preserve the snapshot exactly. A team using it for dispatch, public listings, or sales operations may need a more frequent verification process for the fields that affect its decisions. Those two uses should not be treated as interchangeable. Document the release version, the selected categories, any filters or enrichments, and the last verification date. That short record gives colleagues and clients a clearer basis for judging a result.

When a field is missing, avoid filling it with a guess that looks authoritative. The public column profiles make coverage visible, and the signed package carries its schema and notices. Review the profile for each field your project requires, decide how to handle gaps, and retain the distinction between published source values and later additions. If a project needs a business owner, a confirmed decision-maker, or guaranteed deliverability, this location release does not make those claims. Separate verification is necessary before presenting that information as current.

Version 2.0.0 gives teams a structured starting point for U.S. deli and sandwich-shop location work. Its two categories, stable join key, related contacts and provenance, documented snapshot, and three license packages support different uses without blurring what each number means. Explore the Delicatessens Database product page for the exact tier descriptions, schema, sample files, and current table statistics.