U.S. Publishers and Printing Database Updated: 39,171 Connected Locations

The U.S. Publishers and Printing Database has a new release. Build #162, version 2.0.0, organizes 39,171 selected U.S. locations into a location-centered dataset with progressively richer contact, classification, brand, and historical context across three packages. It is designed for research and product development that need a stable way to connect records, inspect provenance, and choose only the level of detail a project needs.

What changed in this release

The new package starts with a current-source location selection and uses a consistent location_id to connect related tables. That structure matters because a publisher, printer, or support-service location can have more than one contact row or classification. Flattening those relationships into one large row would either lose detail or repeat location data. Separate tables make the relationships explicit, preserve their individual counts, and give analysts a predictable path from a location to the additional detail available in their package.

The selected location table contains 39,171 U.S. locations. The Publication and Master packages add 113,704 published contact rows and 65,368 classification rows. Master adds 1,468 reported brand links across 295 reported brand rows, along with 26 alternate names and matched historical supplemental facts where available. These numbers describe this exact release. They do not claim to count every publisher, printer, or related business in the United States, and they should not be read as a live operating-status census.

The current-source layer uses a documented September 23, 2026 snapshot. Oddity's older first-party release was used as a continuity and enrichment source for confidently matched currently selected locations. Unmatched old listings were kept out of the customer release. Where historical supplemental facts are present, their historical status is labeled rather than silently presented as a current verified attribute.

Choose the package that fits the work

Usage: a clean location base

The Usage package includes the selected locations table. It is the practical starting point when a project needs to search, filter, map, or combine location records with its own permitted data. A team might use it to build a geographic exploration tool, compare the distribution of selected facilities across regions, or seed a controlled internal research workflow. Because the package has the same stable location identifiers used in the higher tiers, a later upgrade can add child tables without changing the basic location model.

Usage is deliberately focused. It does not include the separate published contact and classification tables, and it does not imply that every location is currently operating or independently verified by Oddity. A research application should preserve the release date, source context, and any review of the specific records it chooses to surface.

Publication: contacts and classification detail

Publication adds the published contacts and classifications to the Usage location base. These tables are useful when a project needs to describe the selected businesses in more detail, build filters around source classifications, or inspect published contact fields alongside a location. The relationship is through location_id. Join the child tables only when the view or analysis needs them, and expect that one location may have multiple related rows.

A published contact row is a data field, not proof that a person or inbox is reachable today. It also does not grant consent to send marketing messages. Anyone planning outreach should apply their own legal, platform, privacy, suppression, and verification checks before using contact information. For a public directory, editorial review can help distinguish a descriptive listing from an operational claim that has not been verified.

Master: deeper relationships and continuity

Master includes the lower-tier tables and adds reported brand relationships, alternate names, and matched historical supplemental facts where available. It suits projects that need to study how source-reported names and affiliations relate to selected locations, or compare a current-source selection with older Oddity-created facts that can be confidently linked to it.

Brand relationships are reported relationships in the source model, not a legal ownership determination. Alternate names may help a search or matching interface recognize more ways a location has been described. Historical supplemental values need to retain their vintage label in downstream work. Treat them as context for review, not an automatic replacement for a current-source field. Master is the richest package, but it still benefits from field-level judgment and responsible presentation.

How the joins work

Start with the locations table and keep location_id as the key. Join contacts or classifications to locations using that field. For Master, follow the provided relationship tables to connect reported brands and other context back to the selected location. A location with several contacts and several classifications can multiply rows if both child tables are joined directly in one flat query. Aggregate or filter the child tables separately when the goal is one result per location.

For example, a map marker can use one location row as its anchor, display a count of matching classification rows, and open a detail panel that lists the related contacts. A search index can store the location record as its main document and add selected child fields as searchable facets. A research export can preserve the tables separately, making it easier to explain where each value came from. These are implementation patterns, not promises that any particular field is populated for every location.

Each tier includes CSV, JSON, and SQLite deliverables, plus the accompanying schemas, samples, statistics, and documentation. The formats support different working styles: CSV for tabular review and ordinary imports, JSON for application pipelines, and SQLite for relational exploration without first building a database server. Before integrating a package into a public product, inspect the schema and sample records, then test the actual joins and missing-value behavior against the released files.

What the dataset can and cannot tell you

The selection is a structured view of relevant source records, not an exhaustive inventory of the whole industry. Source classifications and reported associations can be useful signals, but a high-stakes decision about a specific business still calls for independent verification. A location may have moved, changed its services, closed, or appeared in source data with incomplete contact details after the snapshot date. Build user interfaces that show the release context and make room for corrections rather than quietly implying live certainty.

Similarly, counts at different table levels answer different questions. There are 39,171 selected location rows, but 113,704 published contact rows. That does not mean 113,704 separate companies, and it does not mean every contact is unique or reachable. The 65,368 classifications are descriptive rows, while 1,468 reported brand links connect a different kind of relationship. The diagram above keeps those units visible so that a report or application does not turn a child-row count into a business count.

Oddity used confidently matched legacy facts to provide context where they fit the current selected population. The older release did not become a pool of extra unmatched businesses added to inflate the new count. Historical values are best used with their status and vintage intact. This separation is especially important when combining years of data in an analytics product, where an old descriptive field can otherwise look indistinguishable from a current observation.

Practical ways to put it to work

A publisher or print-industry research project might begin with Usage to see how selected locations distribute across a region. A software team building a searchable reference could use Publication to add classification facets and published contact context. A Master project might study source-reported brand relationships or compare current records with carefully labeled historical facts. In each case, the release provides a connected starting point; the application owner decides which fields to show, what to verify, and how to explain its own results.

If the project calls for a single location on a page, make the location row the primary object and show related records as sections. If it calls for a broader comparison, aggregate by the specific measure being reported and label that measure. If it calls for user contact, add consent and deliverability processes outside the dataset itself. Those choices make the data easier to trust because the interface describes what was actually measured.

The product page has the current package details, licensing route, and download information. Review the tier descriptions and sample material there before choosing a package. The release date and version matter when comparing files with an earlier Oddity package or checking whether a stored integration needs to be refreshed.

This announcement describes the October 10, 2026 product update. The data reflects its documented source snapshot and release package, while individual real-world records can change.