Adding your own tables to a SQL database is a good option. It could be the same database as Epi or not.
Then you can use SqlClient or Dapper or EF or whatever you're comfortable with.

If you are hosting on Azure, Table Storage could be a good cheap option. A bit pricier but with more features is Cosmos DB, previously DocumentDB.

It's good practise to use an interface to describe the storing service and make an implementation for the chosen storage service.

You could also build a separate API app that you communcate with or use a Cloud service such as Epi Social for these types of use cases.

Thanks a lot. Right now I am using local db as I am still in development phase. 

Do you have a link to some tutorial where it is making a db queries in EP servever. 

And I think I would choose to keep it is one DB using the same as EP one as I just have to make two small tables. 

Then it really has nothing to do with Episerver besides sharing the same connectionStringName, "EPiServerDB".

I think Dapper is a good option. More lightweight than EF and easier to map objects than using plain .NET SqlClient.

Here's some easy getting started advice: https://www.infoworld.com/article/3025784/application-development/how-to-work-with-dapper-in-c.html

How about using EpiServer DDS?

I wouldn't use DDS for anything but that's just a personal opinion.

I've done a bookmark function before with DDS. The pros doing it with DDS is that there's no need for new packages and no need for custom tables. However in your case the folder requirement makes it trickier.

Some considerations when doing this is just that won't be a link reference if you add reference to DDS. So if page is removed you should remove all bookmarks to this page. You will also need to check access rights specific before listing bookmarks in case they have changed.

Another thing to consider is to verify is if your requests are cached. If i remember correctly load by id is but "queries" will not be.

Sebastian, your concerns are valid regardless of which storage strategy author might choose :)

DDS is elegant for simple, easy, straightforward storage when you need just to persist something and make a simple queries against that. you don't need to install anything, don't need to think about database connection management, don't need to think about schema and migrations. and also you have UI for viewing or editing saved data.

However, on the other hand EF opens up more flexibilities, might be richer query support and you can choose your model persistance schema (tables and indexes, etc) if you need to. can also workaround migrations and make them automatic.

we actually found a simple middleway - lots or things nowadays in our projects are stored in azure table/blob storage. fast, easy to work with, cheap.