Yes. It is, in practice, incredibly different.

Imagine you have a file named /some/dir/file.jpg.

In a filesystem, there’s an inode for /some. It contains an entry for /some/dir, which is also an inode, and then in the very deepest level, there is an inode for /some/dir/file.jpg. You can rename /some to /something_else if you want. Think of it kind of like a table:

  +-------+--------+----------+-------+
  | inode | parent |     name |  data |
  +-------+--------+----------+-------+
  |     1 | (null) |     some | (dir) |
  |     2 |      1 |      dir | (dir) |
  |     3 |      2 | file.jpg |  jpeg |
  +-------+--------+----------+-------+

In S3 (and other object stores), the table is like this:

  +-------------------+------+
  | key               | data |
  +-------------------+------+
  | some/dir/file.jpg | jpeg |
  +-------------------+------+

The kind of queries you can do is completely different. There are no inodes in S3. There is just a mapping from keys to objects. There’s an index on these keys, so you can do queries—but the / character is NOT SPECIAL and does not actually have any significance to the S3 storage system and API. The / character only has significance in the UI.

You can, if you want, use a completely different character to separate “components” in S3, rather than using /, because / is not special. If you want something like “some:dir:file.jpg” or “some.dir.file.jpg” you can do that. Again, because / is not special.