As many of you know, we’re actively working on what we’ve dubbed ‘Lists 2.0’—this is what many Anytype users know as Queries, Collections, Sets, Object Types, etc. As this is an incredibly important feature, we’re also deeply thinking about choosing a good name, as it imparts a strong impression on new users trying to onboard to Anytype. Here are some initial options:
Lists
Collections
Queries
Sets
Databases
Bases
Catalogs
Tables
Listbox
Something else…
0voters
This is a call for community input on the name of the general feature related to objects having properties, views, filters, sorts, etc. Important notes:
There is a lot of architectural work going on behind the scenes of how the feature works, but we want to avoid having that discussion in this thread as it can get off topic very quickly.
Ignore the past naming or current implementation. Just think about if you had to explain this feature to a friend who is new to Anytype, what would you call it?
We recognise this conversation has taken place multiple times in the past, however we want to take a fresh perspective in 2026.
We welcome new suggestions not on the list and feedback.
Edit: Reset Poll: apologies to previous voters, I added an option due to community request and that caused a reset of the poll. Feel free to vote again, however I do mentally recall the votes from before (as noted below).
This seems like a valuable thing to discuss, thanks for requesting feedback.
I would argue against using the word “lists” because I think that would be confusing. The most immediate things that come to mind with “lists” are the bullet and number list options for formatting content. Those are about as straightforward list-y as you can get and they’re properly labeled as lists in the AnyType slash menu. Whereas the functionality provided by this new “Lists 2.0” feature is not a mere list, it’s far more and it provides something that can be used quite differently. I think a similar argument can be made against using the term “tables” which also exist as a type of formatting for content within an object.
I worry that “databases” would imply something unnecessarily complex for this context.
Of the initial options provided, I would vote for “Collections.” Its meaning pretty well reflects what a person sees: a particular collection of some notes or other objects. A Collection (I’m imagining it would likely still have some kind of views) could have a variety of queries that result in what a person sees in it. Also, unless I’m mistaken, I don’t think it has a meaning used in other contexts in AnyType.
Another option might be to invent a new word just for the purpose. Like… I don’t know, an “AnyBase.” But that risks creating confusion because it probably requires explanation. I’m not sure if there’s a way to do that, which would be immediately useful to a new user. Maybe…
Lists is a terrible name. As @owlyph pointed out people just think of bullet point lists/views.
Collections is a more friendly (less technical) way of saying databases. It may not be 100% immediately obvious what it is, but it’s also not misleading (like lists would be). If you’re wanting to be different from Notion I’d pick this.
Queries is also a terrible name. A query indicates that you’re searching for data, not creating data.
Sets, not terrible, but collections is just better.
Databases is the most clear (after tables). This is the terminology that Notion uses and therefore it would be easy for people migrating from notion (and other applications) to understand. If you’re wanting to more directly be a notion alternative use this name.
Bases is really just a shorthand form of databases. Imo it’s kinda silly and just an attempt to say “database” while being different. It would be better to just use database instead.
Catalogs. I personally don’t like it. Makes me think of those thick store magazines. I might be showing my age here tho.
Tables is the most technically accurate and clear. So if you’re going for pure accuracy you would want to pick this one.
I think my vote would be collections then databases. It really depends on how similar to Notion you want to be. From what I’ve seen you’re wanting to be a Notion competitor, but not a Notion clone. So I vote collections.
Searching for obsidian bases tutorials and questions and stuff is easy. Searching for [product name] “database” would give results about the database used of the product and it becomes hell.
So:
tables, database, sets, query and lists are all out because they collide in one or more ways
catalogue is ugly af but at least it would work
collection is a good choice but it collides a little with the past of anytype itself
bases would probably be the best, to also align with obsidian
Said that, i’d simply add a ‘‘smart’’/’’dynamic’’ adjective for the automatic version
Dynamic Base when talking about Sets/queries and Base or Static Base (in the docs) for the collections
Please let’s not let branding and nitpicking win over the practicality of exchanging infos
it would be helpful to hear more use cases - it’s hard to pick names in the abstract.
this is also a branding exercise: how do you want people to think about the product?
The list looks like it was written by developers. There may be strong architectural reasons to unify collections/queries/lists/etc. into a “base class”, but >99% of users don’t care what the data structure is called. If it’s intuitive and is close to existing mental models, there’s a shorter time to that “aha” moment when someone imagines what they could do with it, and they’re hooked. TLDR: allow the namespaces to diverge. Use attributes to align Ui terms with code, not base class names.
follow-up: it’s hard to predict the future (how users will want to use it), so a more abstract term allows it to be mapped into more domains.
Personal opinions:
I agree that Lists and Catalogs are way too specific for the breadth of use cases. Tables makes me think of rows and columns, but I don’t think of a music playlist or a todo list as a table - in my mental model it’s an ordered list or set of things that might be displayed as a table, with columns for extra features or attributes. Groups might be a candidate except that (I think) people associate it more with groups of people, so possibly too limiting.
I like Sets as intuitive, abstract enough to apply to lots of domains, and easily maps to group, collection, query-results or list
I also don’t think it would be awful to have multiple terms. For example, Collection and Query have very different behaviors, so it’s useful to call them different things. (You could to that with adjectives, I suppose, like Dynamic Sets, or Collections and Smart Collections, as Lightroom does for photos)
Thanks for your feedback, @comet. We’ve purposely avoided talking about specific use cases in this exercise because we’re genuinely curious to hear the thoughts of how existing users of Anytype (who understand it well) view the feature in their eyes and how they would describe it to somebody else. This is also why we’ve avoided talking about architecture and implementation in this thread.
And while I agree that users “don’t care what it’s called”, there’s just the practical need that we have to address the feature by a name. Both in the product and in onboarding materials.
I’d go with Databases, like in Notion. It’s descriptive and straight to the point.
I think it’s become standard terminology, together with Properties, another Notion term that Anytype adopted (great choice imo). I remember people being confused when they were called Relations.
And while I agree that users “don’t care what it’s called”, there’s just the practical need that we have to address the feature by a name. Both in the product and in onboarding materials.
That “don’t care” was meant to refer to what the code or APIs call it.
If it wasn’t clear from my message, I think it’s very important what it’s called externally, so important, that it outweighs the lesser goal of having the external product/UI name(s) be consistent with the names used by developers (which don’t appear in onboarding materials)
Although Capacities and Tana popularized and standardized the term “Queries” it seems that “Collection” could cover a wider range of activities and is symbolically more representative than any other terminology.
@kaye this topic was already heavily discussed earlier.
“List” would be really terrible choice, for many reasons.
I strongly suggest to name the thing “Listbox”.
I’ve explained the reasons for example here:
And also here:
I foresee a lot confusion if the thing gets the name “List”. I can already imagine posts from new users in this style: “I have a list that misses entries …”
– Many posts later comes out, that he didn’t speak about the combined Collection/Query-thing, but about something totally different, for example the list of Tags in a Multi-Select. Or a numbered list in the editor.
Also think about the search function in this forum!
If someone looks for a solution and he uses the forum search.
“List” is a much too general term; you’ll find endless irrelevant posts that contain this term!
– I urge you: please give the thing a unique name that can’t be confused with anything else!
“Listbox”:
Fulfills this criteria.
Is a nice short term.
Is also a “speaking name” – a newcomer doesn’t need to think a lot about its function.
It’s a box in which you’ll see lists. The name says that.
Once understood, it’ impossible to forget what it means and what the thing does. – This is important for getting newcomers quickly “on board” (before they give up, overwhelmed by the complexity and the many things to lern).
Lists: terrible because there are already two kinds of lists in Anytype, bulleted and numbered lists. There is also a ‘list’ view.
Collections: great because it’s technically accurate (we’re talking about collecting objects into a single location, either manually or through automation) and accessible to non technical users.
Queries: inaccessible to most people, and also technically inaccurate (a manual collection doesn’t query objects)
Sets: not easy to understand
Databases: not terrible but also not very accessible to the non technical user
Bases: inaccessible and not easy to understand
Catalogs: unusual and odd for a feature in a tech product. A catalog also implies a very visual interface, akin to a gallery.
Tables: technically inaccurate, as they are many views for lists/collections/queries, many of which do not take the form of a table. And more importantly there is already a table block.
In short: Collection is the most promising, database is an acceptable second
i like “List” - to me, that is just the most basic and easiest to understand, thats all a database really is anyways when you break it down into its most simplest form.
that being said, what about “library”?
Queries - does sound like a search, not a list or database or collection. I personally dont think that really works.
When you’re thinking about a suitable term for something, you first need to know exactly what it does. I’d really like to find out, and maybe others would too.
“We’re actively working on what we’ve dubbed ‘Lists 2.0’” – for me, that’s the only information available at the moment, and probably for many others as well.
Or am I the only one who doesn’t know what this post is about? What is “Lists 2.0”? And what was “Lists 1.0”? The only lists we currently have are a text formatting function.
Where does one find detailed information about the planned changes, which are obviously so profound that one universal term has to be found for them?
In my opinion, it makes absolutely no sense to ask the community to come up with a permanent name for something when the details of the technical implementation of that something have not even been announced yet.
The list of options offered in this post seems like a joke. All of these terms listed here stand for completely different, commonly used, very specific functions (maybe except for “Sets” as a redundancy for “Queries”).
You don’t choose a term according to your preferences and taste like you do with clothes, do you?
And why on earth does a single term have to be found now for so many different functions anyway?
I had the same thoughts when reading the post.
In my opinion, this post is only about involving the community in finding the most well-known/appropriate name that best describes the feature in general, regardless of technical details.
This is a call for community input on the name of the general feature related to objects having properties, views, filters, sorts, etc.
Apologies if it was not clear, @VisualNotes. I expressed this as the feature that relates to, “what many Anytype users know as Queries, Collections, Sets, Object Types, etc.” To be more specific from a visual standpoint, it means this feature where you set properties to objects, filter them, sort them, and organise based on different views such as calendar, gallery, board, etc.:
For the purposes of this discussion, the technical implementation is not relevant at this stage. Anytype users who would respond to this post are already using this feature every day and are familiar with ‘why’ and ‘how’ they use it. For now, we’re simply interested in hearing ‘what’ they would call it. We want to avoid architecture conversations because it is simply irrelevant to a new user trying to quickly understand something conceptually. I understand this is counter-intuitive, however I’d like to think about things from a user perspective first, not from a technical structure.
There are many reasons why we’re looking for a single term, however I would rather not pollute this conversation at this stage.
The community is not deciding on a permanent name, we’re simply soliciting feedback and input. If this is not something you want to participate in, all good—it’s optional.
