If by application database you mean to the level of an RDBMS then no. It's a key-value data store. You get your CRUD operations, expiry, key listing and the ability to do pagination with keys always returning in lexicographically sorted order. Any relation data you want to have would be using the key prefixes, e.g.:

  article:1 -> {"user": 1, "content": "..."}
  user:1 -> {"name": "username"}
  user:1:articles -> [1, ...]

yep. thats the plan. i will have keys like

postid:someid/text

postid:someid/author

etc.

the relation aspect doesnt daunts me. As long as I can have a list/collection as a value, i can define a working schema.

I am more worried about if its costlier than normal dbs. and if there are any other gotchas to keep in mind as kv workers have scant documentation.

If you're comparing this to a normal DB, the biggest worry should be that it's not ACID compliant. Definitely something to consider if your data is important. The limitations for KV is listed here: https://developers.cloudflare.com/workers/about/limits#kv

You should also consider how you intend to backup the data as there currently isn't a process to do that outside of writing something yourself to periodically download the keys. This will add to your usage cost depending on what your strategy is, for example, backing up old keys that gets updated vs only new keys by keeping track of the cursor.